slgdgdy 


Fs 
=m 
Pe 
= 
=_ 
m 
Pal 
= 
m 
=< 
== 
ia 
ani 
= 
TI 
Mm 
i 
Lr 
i = 
di 
"hh 
rm i 
i S| 
= 
i * 
7, 
= 
_ = 
| 
一 
一- 
ty 1 
ii 
rpi, 
TI 
LA 


Effective C++... 


Third Edition 


55 Specific po to Improve 
| s and Designs 
—_— 





天 

到 Pile ij 
- e Ane i gs 
g ae Lg 


[E] Scott Meyers f 


| var 
Peer a Fi: 





= + Ea T£ ial 


Effective C++ 


H $k 


M*A 0 
Preface (AUS) 1 
Introduction ($8) 2 
Terminology (术语 ) 3 
Item 1: 将 C++ 视 为 federation of languages (语言 联合 体 ) 4 
Item 2: 用 consts, enums 和 inlines 取代 #defines 5 
Item 3: 只 要 可 能 就 用 const 6 
Item 4: 确保 objects (xt) 在 使 用 前 被 初始 化 7 
Item 5: 了 解 C++ 为 你 偷偷 地 加 上 和 调用 了 什么 画 数 8 


Item 6: 如果 你 不 想 使 用 compiler-generated functions (编译 器 生成 函数 ) ， 就 明确 拒绝 
Item 7: 在 polymorphic base classes (多 态 基 类 ) 中 将 destructors ( 析 构 画 数 ) 声明 9 


为 virtual (虚拟 ) 10 
Item 8: 防止 因为 exceptions (异常 ) 而 离开 destructors (TERZ) 11 
Item 9: 绝 不 要 在 construction (构造) 或 destruction 〈 析 构 ) 期 间 调用 virtual 
functions (虚拟 函数 ) 12 
Item 10: 让 assignment operators (赋值 运算 符 ) 返回 一 个 reference to \*this ( 引 向 
\*this 的 引用 ) 13 
Item 11: 在 operator= H 422 assignment to self ( 自 赋值 ) 14 
Item 12: 拷贝 一 个 对 象 的 所 有 组 成 部 分 15 
ltem 13: 使 用 对 象 管理 资源 16 
Item 14: 着 慎 考 虑 资源 管理 类 的 拷贝 行为 17 
Item 15: 在 资源 管理 类 中 准 各 访问 裸 资 源 (raw resources) 18 
ltem 16: 使 用 相同 形式 的 new 和 delete 19 
ltem 17: 在 一 个 独立 的 语句 中 将 new 出 来 的 对 象 存 入 智能 指针 20 
Item 18: 使 接口 易于 正确 使 用 ， 而 难以 错误 使 用 21 
ltem 19: 视 类 设计 为 类 型 设计 22 
Item 20: 用 pass-by-reference-to-const 〈 传 引用 给 const) 取代 pass-by-value ( 传 值 ) 
Item 21: 当 你 必须 返回 一 个 对 象 时 不 要 试图 返回 一 个 引用 24 23 
Item 22: 将 数据 成 员 声 明 为 private 25 
Item 23: AJER n IFRA A BZ 26 
Item 24: 5 ž Ei a AFAA SZU, EA JER RK 27 


Effective C++ 


Item 25: 考虑 支持 不 抛 异常 的 swap 28 
Item 26: 只 要 有 可 能 就 推迟 变量 定义 29 
Item 27: 将 强制 转型 减 到 最 少 30 
Item 28: 避免 返回 对 象 内 部 构件 的 "句柄 ” 31 
ltem 29: 争取 异常 安全 (exception-safe) 的 代码 32 
Item 30: 理解 inline 化 的 介入 和 排除 33 
Item 31: 最 小 化 文件 之 间 的 编译 依赖 34 
ltem 32: 确保 public inheritance "is-a" 35 
Item 33: 避免 覆盖 (hiding) “通过 继承 得 到 的 名 字 ” 36 
Item 34: 区 分 inheritance of interface (接口 继承 ) 和 inheritance of implementation ( 实 
MAIR) 37 
Item 35: 考虑 可 选 的 virtual functions (虚拟 函数 ) HERDE 38 
Item 36: 绝 不 要 重 定义 一 个 inherited non-virtual function GHit #kAB AMIE DA 
数 ) 39 
Item 37: 绝 不 要 重 定义 一 个 函数 的 inherited default parameter value ( 通 号 到 的 缺 
省 参数 值 ) 40 
Item 38: 通过 composition (复合 ) 模拟 "has-a" (有 一 个 ) 或 "is-implemented-in-terms- 
of" (是 根据 ..….... 实 现 的 ) 41 
Item 39: 着 愤 使 用 private inheritance (私有 继承 ) 42 
Item 40: 着 愤 使 用 multiple inheritance (多 继承 ) 43 
Item 41: 理解 implicit interfaces ( 隐 式 接口 ) 和 compile-time polymorphism (编译 期 多 
态 ) 44 
Item 42: 理解 typename 的 两 个 含义 45 
Item 43: 了 解 如 何 访问 templatized base classes (模板 化 基 类 ) 中 的 名 字 46 
Item 44: M templates (模板 ) 中 分 离 出 parameter-independent (参数 无 关 ) 的 代码 
Item 45: 用 member function templates (AK A HAAR) 接受 "all compatible 47 
types" (“所 有 兼容 类 型 ”) 48 
Item 46: 需要 type conversions (类 型 转换 ) 时 在 templates (模板 ) 内 定义 non- 
member functions ( 非 成 员 画 数 ) 49 
ltem 47: 为 类 型 信息 使 用 traits classes (特征 类 ) 50 
ltem 48: 感受 template metaprogramming (模板 元 编程 ) 51 
Item 49: 了 解 new-handler 的 行为 52 
Item 50: 领会 何 时 替换 new 和 delete 才 有 意义 53 
Item 51: 编写 new 和 delete 时 要 遵守 惯例 54 
Item 52: 如 果 编 写 了 placement new， 就 要 编写 placement delete 55 


Effective C++ 


附录 A. 超越 Effective C++ 
附录 B. 第 二 和 第 三 版 之 间 的 Item 映射 


56 
57 


Effective C++ 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 


来 源 : http://blog.csdn.net/fatalerror99/ 


Preface (前 言 ) 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


我 在 1991 FSWT Effective C++ 的 最 早 版 本 ，1997 年 出 了 第 二 版 ， 我 更 新 了 一 些 重要 的 方 
面 的 素材 ， 但 是 ， 因 为 我 不 想 使 熟悉 本 书 第 一 版 的 读者 感到 困惑 ， 我 尽 最 大 可 能 保持 了 原 有 
的 结构 。 最 早 的 50 个 Item 标题 中 的 48 个 原则 上 保持 不 变 。 如 果 把 书 看 作 一 栋 房子 ， 第 二 版 
就 相当 于 通过 更 换 地 秘 、 涂 料 和 灯光 设备 等 使 其 焕然 一 新 。 


对 于 第 三 版 ， 我 打 散 了 原 有 的 秩序 。 (很 多 次 我 希望 我 能 做 得 更 彻底 。) 1991 FAR, C++ 
世界 经 历 了 巨大 的 改变 ， 而 将 近 15 年 以 前 我 制定 的 那些 Item 也 不 再 契合 本 书 的 目标 一 将 
最 重要 的 C++ 编程 准则 融入 小 而 易 读 的 建议 中 。1991 F, Bi C++ 程序 员 具 有 C 语言 背景 
是 有 一 定 道理 的 。 现 在 ， 转 到 C++ 的 程序 员 很 可 能 来 自 Java 或 C# 1991 年 ， 

inheritance (继承 ) 和 object-oriented programming (面向 对 象 编 程 ) 对 于 大 多 数 程序 员 来 
说 都 是 新 鲜 的 。 现 在 ， 这 些 已 经 是 非常 普遍 的 概念 ， 而 exceptions (FR) , templates ( 模 
板 ) ， 以 及 generic programming ( 泛 型 编程 ) 成 为 新 的 需要 更 多 指导 的 领域 。1991 年 ， 没 
有 人 听 说 过 design patterns (设计 模式 ) 。 现 在 ， 讨 论 软 件 系统 时 很 难 不 涉及 它们 。1991 
年 ，C++ 正式 标准 化 的 工作 刚刚 开始 。 现 在 ， 标 准 化 已 经 八 年 了 ， 而 下 一 个 版 本 的 工作 也 已 
经 开始 。 





为 应 对 这 些 变化 ， 我 尽 己 所 能 将 写字 板 擦 得 一 干 二 净 ， 并 不 断 地 追问 自己 : "在 2005 年 ， 对 
于 目前 的 C++ 程序 员 ， 什 么 机 是 最 重要 的 建议 ? "结果 就 是 这 个 新 版 本 中 的 一 组 tem A 
包括 了 关于 resource management (资源 管理 ) 和 programming with templates (使 用 模板 
编程 ) 的 新 的 章节 。 实 际 上 ，templates (模板 ) 的 考虑 贯穿 全 书 ， 因 为 它 几 乎 影响 了 C++ 的 
每 个 方面 。 本 书 也 包括 关于 在 exceptions (异常 ) 存在 的 场合 下 编程 ， 在 应 用 design 
patterns (设计 模式 ) ， 以 及 在 使 用 新 的 TR1 库 程序 (TR1 在 Item 54 中 介绍 ) 等 方面 的 新 
的 素材 。 本 书 还 承认 在 single-threaded systems (单线 程 系统 ) 中 能 很 好 地 工作 的 技术 和 方 
法 可 能 不 适用 于 multithreaded systems (多 线程 系统 ) 。 噢 ， 本 书 超过 一 半 的 素材 都 是 新 
的 。 然 而 ， 第 二 版 中 基本 原理 方面 的 资料 中 的 大 部 分 依然 是 重要 的 ， 所 以 我 将 它们 以 这 样 或 
那样 的 形式 保留 下 来 。 (你 能 在 Appendix B (附录 B) 找到 第 二 版 和 第 三 版 Item 的 对 照 
表 。) 


我 尽 我 所 能 使 本 书 趋 于 最 好 ， 但 我 并 不 幻想 完美 。 如 果 你 觉得 本 书 中 的 一 些 Item 作为 常规 的 
建议 不 太 合适 ; 或 者 有 更 好 的 方法 实现 本 书 中 需要 完成 的 任务 ; 或 者 有 一 个 或 更 多 技术 上 的 
讨论 不 明确 ， 不 完全 ， 或 容易 伟人 误解 ， 请 告诉 我 。 如 果 你 发 现任 何 错误 一 一 技术 上 的 ， 文 
法 上 的 ， 印 刷 上 的 ， 无 论 哪 种 一 一 也 请 告诉 我 。 如 果 你 是 第 一 个 让 我 注意 到 某 个 问题 的 人 ， 

我 很 高 兴 将 你 的 名 字 加 入 到 以 后 再 次 印刷 的 致谢 中 。 





即使 Item 的 数量 增加 到 55， 本 书 中 的 这 一 组 准则 离 完 满 无 遗 还 差 得 很 远 。 但 是 成 为 好 的 规则 
一 在 几乎 所 有 的 应 用 程序 几乎 所 有 的 时 间 中 得 到 应 用 一 比 它 看 上 去 更 加 困难 。 如 果 你 有 
增加 准则 的 建议 ， 我 很 高 兴 能 听 到 它 。 


我 维护 本 书 从 第 一 次 印刷 起 的 变化 列表 ， 包 括 错 误 修正 ， 进 一 步 解释 ， 和 技术 更 新 。 这 个 列 
表 可 以 从 Effective C++ Errata 网 页 得 到 ，http://aristeia.com/BookErrata/ec++3e- 
errata.html。 如 果 你 希望 当 我 更 新 列表 时 ， 你 能 得 到 通报 ， 我 建议 你 参加 我 的 mailing list (ap 
件 列 表 ) 。 我 用 它 作 为 通告 ， 发 给 那些 对 跟踪 我 的 职业 工作 感 兴趣 的 人 们 。 关 于 细节 问题 ， 
请 参考 http://aristeia.com/MailingList/。 


SCOTT DOUGLAS MEYERS STAFFORD, OREGON hitp://aristeia.com/ APRIL 2005 


Introduction ($8) 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


学 习 一 种 编程 语言 的 基础 是 一 回 事 ; 学 习 如 何 用 那 种 语言 设计 和 实现 高 效率 的 程序 完全 是 另 
外 一 回 事 。 对 于 C++ 一 种 以 拥有 非 同 寻常 的 能 力 范围 和 表现 力 而 自豪 的 语言 一 更 是 尤 
其 如 此 。 如 果 能 正确 使 用 ， 与 C++ 共事 是 一 件 合 人 快乐 的 事情 。 极 多 样 的 设计 样式 被 直接 表 
达 并 有 效 实现 。 对 于 classes (#) , functions (HX) ， 以 及 templates (模板 ) 的 明智 选 
择 和 小 心 精巧 的 安排 能 使 应 用 程序 的 编程 更 加 简单 ， 直 观 ， 高 效 ， 并 基本 无 错 。 如 果 你 知道 
如 何 去 做 ， 写 出 高 效 的 C++ 程序 并 不 特别 难 。 然 而 ， 如 果 不 经 训练 就 贸然 使 用 ，C++ 也 会 导 
致 不 可 理解 的 ， 难 以 维护 的 ， 无 法 扩展 的 ， 低 效率 的 ， 错 误 百 出 的 代码 。 





本 书 的 目的 在 于 引导 你 如 何 高 效 使 用 C++。 我 假设 你 已 经 熟悉 了 作为 语言 的 C++ 并 有 使 用 它 
的 一 些 经 验 。 我 在 此 提供 的 是 使 用 这 种 语言 的 指南 ， 以 使 你 的 程序 易于 理解 ， 可 维护， 易 移 
植 ， 可 扩展 ， 效 率 高 ， 而 且 行 为 符合 你 的 预期 。 


我 提供 的 建议 落 在 两 个 主要 的 范围 中 : 普通 的 设计 策略 ， 以 及 特殊 语言 特性 的 具体 细节 。 设 
计 的 讨论 集中 于 如 何在 C++ 做 某 件 事情 的 多 种 不 同方 法 之 间 进 行 选择 。 如 何在 

inheritance (继承 ) 和 templates (模板 ) 之 间 选 择 ? 如 何在 public( 公 有) 和 private 
inheritance 〈 私 有 继承 ) 之 间 选 择 ? 如 何在 private inheritance (私有 继承 ) 和 

composition (复合 ) 之 间 选 择 ? 如 何在 member (成 员 ) 和 non-member functions ( 非 成 员 
函数 ) 之 间 选 择 ? 如 何在 pass-by-value 〈 传 值 ) 和 pass-by-reference ( 传 引用 ) 之 间 选 择 ? 
在 一 开始 就 做 出 正确 的 决定 是 很 重要 的 ， 因 为 一 个 不 好 的 选择 可 能 会 直到 开发 过 程 很 晚 的 阶 
段 才 显现 出 来 ， 在 这 时 候 再 调整 它 常常 是 困难 重重 ， 极 为 耗 时 而 且 代 价 不 菲 的 。 


即使 在 你 正确 地 知道 你 要 做 什么 的 时 候 ， 仅 仅 把 事情 做 对 也 是 需要 技巧 的 。assignment 
operators (赋值 运算 符 ) 的 合适 的 返回 类 型 是 什么 ? destructor (MARZO 什么 时 候 应 该 是 
virtual (虚拟 ) 的 ? 当 operator new (运算 符 new) 找 不 到 足够 的 内 存 时 它 应 该 怎么 办 ? KW 
这 些 的 伟人 费 神 的 细节 是 至 关 重 要 的 ， 因 为 错误 的 做 法 几乎 总 是 导致 无 法 预料 的 ， 很 可 能 兮 
人 迷惑 的 程序 行为 。 这 本 书 正 是 来 帮助 你 避免 这 些 问题 的 。 


这 不 是 一 本 全 面 的 C++ 手册 。 它 收集 了 55 个 详细 的 提议 (我 将 它们 称 为 Items) 告诉 你 怎样 
才能 改善 你 的 程序 和 设计 。 每 一 个 ltem 都 能 stands more orless on its own (独立 成 章 ) ， 
但 大 部 分 也 包含 对 其 它 Items 的 参考 。 因 而 ， 读 这 本 书 的 一 个 方法 就 是 从 你 感 兴趣 的 一 个 
ltem 开始 ， 然 后 顺 着 它 的 参考 条 目 继续 看 下 去 。 


这 本 书 也 不 是 一 本 C++ ANH. PIM, Œ Chapter 2 (第 二 章 ) ， 我 希望 能 告诉 你 关于 
constructors (ARZ) , destructors 〈 析 构 函 数 ) ， 以 及 assignment operators (WA 
算 符 ) 正确 实现 的 全 部 内 容 ， 但 是 我 假设 你 已 经 知道 或 者 能 在 别处 找到 这 些 范 数 做 些 什么 以 
及 它们 该 怎样 声明 的 资料 。 大 量 C++ 书籍 包含 类 似 这 样 的 信息 。 


这 本 书 的 目的 是 为 了 突出 C++ 编程 中 那些 常常 被 忽略 的 方面 。 其 它 书 描述 了 语言 的 各 个 部 
分 。 这 本 书 则 告诉 你 如 何 和 将 这 些 部 分 结合 起 来 以 达到 高 效 编程 的 最 终 目 的 。 其 它 书 告诉 你 如 
何 使 你 的 程序 能 够 编译 。 这 本 书 则 告诉 你 如 何 避 免 那些 编译 器 不 能 告诉 你 的 问题 。 


与 此 同时 ， 本 书 将 自己 限制 在 standard C++ (标准 C+) 之 内 。 在 此 仅仅 使 用 官方 的 语言 标 
准 中 的 特性 。 可 移植 性 是 本 书 一 个 关键 的 关注 点 ， 所 以 如 果 你 要 寻找 平台 依赖 的 特性 和 部 
件 ， 在 这 里 不 会 找到 。 


另 一 个 在 本 书 中 找 不 到 的 未 西 是 C++ Gospel (C++ 福音 书 ) 一 一 通 向 完美 的 C++ 软件 的 一 
条 One True Path (真理 之 路 ) 。 本 书 中 的 每 一 个 Item 都 在 如 何 生成 更 好 的 设计 ， 如 何 避 免 
一 般 的 问题 ， 以 及 如 何 得 到 更 高 的 效率 等 方面 提供 指导 ， 但 没有 一 个 Item 是 普 表 适用 的 。 坎 
件 设计 和 实现 是 一 项 复杂 的 任务 ， 被 hardware (硬件 ) , operating system (操作 系统 ) ， 
和 application (应 用 程序 ) 的 限制 所 影响 ， 所 以 我 能 做 的 最 好 的 事情 就 是 为 创建 更 好 的 程序 
提供 guidelines (指导 方针 ) 。 


如 果 你 在 所 有 的 时 候 都 遵守 这 些 guidelines (指导 方针 ) ， 你 将 不 太 可 能 落 入 环绕 在 C++ A 
围 的 大 量 陷阱 中 ， 但 是 作为 guidelines (指导 方针 ) 的 固有 限制 ， 它 总 有 例外 。 这 就 是 为 什么 
每 一 个 ltem 都 有 一 个 详细 的 解释 。 这 些 解释 是 本 书 中 最 重要 的 部 分 。 只 有 理解 了 一 个 Item 

背后 的 基本 原理 ， 你 才能 决定 它 是 否 适 合 你 开发 的 软件 以 及 你 被 困 其 下 的 特有 的 限制 。 


本 书 最 好 用 来 增加 关于 C++ 如 何 运转 ， 为 什么 它 会 这 样 运转 ， 以 及 如 何 让 它 的 行为 为 你 服务 
等 方面 的 知识 。 盲 目 运 用 本 书 的 ltems 无 疑 是 不 适当 的 ， 但 是 与 此 同时 ， 如 果 你 没有 更 好 的 
理由 ， 或 许 也 不 应 该 违反 这 些 guidelines (指导 方针 ) 中 的 任何 一 条 。 


Terminology (术语 ) 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


这 是 一 个 所 有 程序 员 都 应 该 了 解 的 小 型 的 C++ vocabulary (词汇 表 ) 。 下 面 的 术语 都 足够 重 
要 ， 对 它们 的 含义 取得 完全 一 致 对 于 我 们 来 说 是 完全 必要 的 。 


declaration (声明 ) 告诉 编译 器 关于 某 物 的 name (名 字 ) 和 type (类 型 ) ， 但 它 省 略 了 某 些 
细节 。 以 下 这 些 都 是 declaration (声明 ) 


extern int x; // object declaration 

std::size_t numDigits(int number); // function declaration 
class Widget; // class declaration 

template<typename T> // template declaration 

class GraphNode; // (see Item 42 for info on 


// the use of "typename") 


注意 即使 是 built-in type (内 建 类 型 ) ， 我 还 是 更 喜欢 将 整数 x 看 作 一 个 "object"， 某 些 人 将 
"object" 这 个 名 字 保留 给 user-defined type (用 户 定义 类 型 ) ， 但 我 不 是 他 们 中 的 一 员 。 再 有 
就 是 注意 函数 numDigits 的 返回 类 型 是 std::size_t， 也 就 是 说 ，namespace (命名 空间 ) std 
中 的 size_t 类 型 。 这 个 namespace (命名 空间 ) 是 C++ 标准 库 中 每 一 样 东 西 实际 所 在 的 地 
方 。 但 是 ， 因 为 C 标准 库 (严谨 地 说 ， 来 自 于 C89) 在 C++ 中 也 能 使 用 ， 从 C 继承 来 的 符 
号 (诸如 size t) 可 能 存在 于 全 局 范围 ， 或 std 内 部 ， 或 两 者 都 有 ， 这 依赖 于 哪 一 个 头 文件 被 
#include。 在 本 书 中 ， 我 假设 C++ 头 文件 被 #include， 这 也 就 是 为 什么 我 用 std::size t 代替 
size_t 的 原因 。 当 文字 讨论 中 涉及 到 标准 库 组 件 时 ， 我 一 般 不 再 提 及 std， 这 依赖 于 你 认可 类 
似 size_t, vector, LR cout 之 类 的 东西 都 在 std 中 ， 在 示例 代码 中 ， 我 总 是 包含 std， 因 为 
真正 的 代码 没有 它 将 无 法 编译 。 


顺便 说 一 下 ，size_t 仅仅 是 供 C++ 对 某 物 计数 时 使 用 的 某 些 unsigned 类 型 的 typedef (fil 
如 ， 一 个 char*-based string (基于 char 的 string) 中 字符 的 个 数 ， 一 个 STL container ( 容 
器 ) 中 元 素 的 个 数 ， 等 等 ) 。 它 也 是 vector，deque， 和 string 的 operator[] HARE AA % 
型 ， 这 是 一 个 在 ltem 3 中 定义 我 们 自己 的 operator] 本 数 时 将 要 遵守 的 惯例 。 


每 一 个 画 数 的 declaration (声明 ) 都 表明 了 它 的 signature (识别 特征 ) ， 也 就 是 它 的 参数 和 
返回 类 型 。 一 个 画 数 的 signature (识别 特征 ) 与 它 的 类 型 相同 。 对 于 numDigits 的 情况 ， 
signature (识别 特征 ) 是 std::size_t (int), tmx, “KAREA int， 并 返回 一 个 


std::size_t’, BABY "signature" (识别 特征 ) 的 C++ 定义 排除 了 男 数 的 返回 类 型 ， 但 是 在 本 
书 中 ， 将 返回 类 型 考虑 为 signature (识别 特征 ) 的 一 部 分 更 加 有 用 。 


definition (定义 ) 为 编译 器 提供 在 declaration (EB) 时 被 省 略 的 细节 。 对 于 一 个 

object (对 象 ) ，definition (定义 ) 是 编译 器 为 object (GR) 留 出 内 存 的 地 方 。 对 于 一 个 
function (2) 或 一 个 function template (EVER) , definition (EX) 提供 代码 本 体 。 
对 于 一 个 class (类 ) 或 一 个 class template (类 模板 ) ，definition (定义 ) 列 出 了 

class (类 ) 或 者 template (模板 ) 的 members (AK A) 


int x; // object definition 

std::size_t numDigits(int number) // function definition. 
{ // (This function returns 

std::size_t digitsSoFar = 1; // the number of digits 
// in its parameter.) 

while ((number /= 10) != 0) ++digitsSoFar; 

return digitsSoFar; 

} 

class Widget { // class definition 

public: 

Widget(); 


~Widget(); 


}; 

template<typename T> // template definition 
class GraphNode { 

public: 

GraphNode(); 


~GraphNode(); 


initialization (初始 化 ) 是 设 定 一 个 object (4R) 的 第 一 个 值 的 过 程 。 对 于 user-defined 
types (用 户 定义 类 型 ) 的 objects (对 象 ) initialization (初始 化 ) 通过 constructors (构造 
函数 ) 完成 。default constructor (WAERO 就 是 不 需要 任何 arguments (51%) 就 可 
以 调用 的 那 一 个 。 这 样 的 一 个 constructor WARA) 既 可 以 是 没有 parameters (SR) ， 
也 可 以 是 每 一 个 parameter (参数 ) MARAE : 


class A { 

public: 

A(); // default constructor 

}; 

class B { 

public: 

explicit B(int x = 0, bool b = true); // default constructor; see below 
}; // for info on "explicit" 

class C { 

public: 

explicit C(int x); // not a default constructor 
}; 


这 里 classes B 和 C 的 constructors (构造 男 数 ) 都 被 声明 为 explicit ( 显 式 ) 。 这 是 为 了 防 
止 它们 被 用 来 执行 implicit type conversions ( 隐 式 类 型 转换 ) ， 虽 然 他 们 还 可 以 被 用 于 
explicit type conversions (显示 类 型 转换 ) 


void doSomething(B bObject); // a function taking an object of 
// type B 

B bObj1; // an object of type B 

doSomething(b0bj1); // fine, passes a B to doSomething 
B bObj2(28); // fine, creates a B from the int 28 

// (the bool defaults to true) 

doSomething(28); // error! doSomething takes a B, 

// not an int, and there is no 

// implicit conversion from int to B 
doSomething(B(28)); // fine, uses the B constructor to 
// explicitly convert (i.e., cast) the 

// int to a B for this call. (See 


// Item 27 for info on casting.) 


constructors (ERN) 被 声明 为 explicit (50) 通常 比 non-explicit (JER) BAR, 
因为 它们 可 以 防止 编译 器 执行 意外 的 (常常 是 无 意识 的 ) type conversions (类 型 转换 ) o BR 
非 我 有 一 个 好 的 理由 允许 一 个 constructor (构造 函数 ) 被 用 于 implicit type conversions (14 
式 类 型 转换 ) ， 否 则 我 就 将 它 声 明 为 explicit 〈 显 式 ) 。 我 希望 你 能 遵循 同样 的 方针 。 


请 注意 我 是 如 何 突出 上 面 的 示例 代码 中 的 cast (强制 转换 ) 的 。 贯 穿 本 书 ， 我 用 这 样 的 突出 
引导 你 注意 那些 应 该 注意 的 材料 。 (我 也 突出 章节 号 码 ， 但 那 仅 仅 是 因为 我 想 让 它 好 看 一 


些 。) 


copy constructor (拷贝 构造 画 数 ) 被 用 来 以 一 个 object (对 象 ) 来 初始 化 同类 型 的 另 一 个 
object (对 象 ) , copy assignment operator (拷贝 赋值 运算 符 ) 被 用 来 将 一 个 object (对 
R) 中 的 值 拷 贝 到 同类 型 的 另 一 个 object (对 象 ) 中 : 


class Widget { 

public: 

Widget(); // default constructor 

Widget(const Widget& rhs); // copy constructor 


Widget& operator=(const Widget& rhs); // copy assignment operator 


J; 

Widget wi; // invoke default constructor 
Widget w2(w1); // invoke copy constructor 
wi = w2; // invoke copy 


// assignment operator 


当 你 看 到 什么 东西 看 起 来 像 一 个 assignment (赋值 ) 的 话 ， 要 仔细 阅读 ， 因 为 "=" 在 语法 上 
还 可 以 被 用 来 调用 copy constructor (拷贝 构造 画 数 ) 


Widget w3 = w2; // invoke copy constructor! 


幸运 的 是 ，copy constructor (#4 A Mis HR) 很 容易 从 copy assignment (拷贝 赋值 ) 中 区 
别 出 来 。 如 果 一 个 新 的 object 〈 对 象 ) 被 定义 (就 象 上 面 那 行 代码 中 的 w3) ， 一 个 
constructor (DER) 必须 被 调用 ; 它 不 可 能 是 一 个 assignment (赋值 ) 。 如 果 没 有 新 的 
object (GR) 被 定义 (就 象 上 面 那 行 "w1 = w2" 代码 中 ) ， 没 有 constructor (构造 画 数 ) 能 
被 调用 ， 所 以 它 就 是 一 个 assignment (赋值 ) o 


copy constructor (H 416M) 是 一 个 特别 重要 的 函数 ， 因 为 它 定义 一 个 object (tk) 
如 何 passed by value (通过 传 值 的 方式 被 传递 ) 。 例 如 ， 考 虑 这 个 : 


bool hasAcceptableQuality(Widget w); 


Widget aWidget; 


if (hasAcceptableQuality(aWidget)) ... 


参数 w 通过 传 值 的 方式 被 传递 给 hasAcceptableQuality， 所 以 在 上 面 的 调用 中 ，aWidget 被 
拷贝 给 Ww。 拷 贝 动 作 通 过 Widget 的 copy constructor (742 HISAR) 被 执行 。pass-by- 
value (通过 传 值 方式 传递 ) 意味 着 "call the copy constructor" GAA nEn) 。 ( 然 
而 ， 通 过 传 值 方式 传递 user-defined types (用 户 定义 类 型 ) 通常 是 一 个 不 好 的 想法 ，pass- 
by-reference-to-const ( 传 引 用 给 const) 通常 是 更 好 的 选择 。 关 于 细节 ， 参 见 ltem 20。) 


STL 是 Standard Template Library (标准 模板 库 ) ， 作 为 C++ 标准 库 的 一 部 分 ， 致 力 于 
containers (容器 ) (例如 ，vector，list，set，map， 等 等 ) iterators (迭代 器 ) (例如 ， 
vector<int>::iterator，set<string>::iterator， 等 等 ) algorithms (算法 ) 〈 例 如 ，for_each， 
find, sort, SS) ， 以 及 相关 机 能 。 相 关机 能 中 的 很 多 都 通过 function objects (WAR) 
一 一 行为 表现 类 似 于 函数 的 objects (4R) 一 一 提供 。 这 样 的 objects (tk) 来 自 于 重 载 了 
operator() 函数 调用 运算 符 一 的 class (类 ) ， 如 果 你 不 熟悉 STL， 在 读本 书 的 时 候 ， 
你 应 该 有 一 本 像样 的 参考 手册 备查， 因为 对 于 我 来 说 STL 太 有 用 了 ， 以 至 于 不 能 不 利用 它 。 
一 但 你 用 了 一 点 点 ， 你 也 会 有 同样 的 感觉 。 





从 Java 或 C# 那样 的 语言 来 到 C++ 的 程序 员 可 能 会 对 undefined behavior (未 定义 行为 ) 的 
概念 感到 吃惊 。 因 为 各 种 各 样 的 原因 ，C++ 中 的 一 些 constructs (结构 成 分 ) 的 行为 没有 确 
切 的 定义 : 你 不 能 可 靠 地 预知 运行 时 会 发 生 什么 。 这 里 是 两 个 带 有 undefined behavior (RE 
义 行 为 ) 的 代码 的 例子 : 


int *p = 0; // p is a null pointer 

std::cout &1lt;&lt; *p; // dereferencing a null pointer 

// yields undefined behavior 

char name[] = "Darla"; // name is an array of size 6 (don't 
// forget the trailing null!) 

char c = name[10]; // referring to an invalid array index 


// yields undefined behavior 


为 了 强调 undefined behavior (未 定义 行为 ) 的 结果 是 不 可 预言 而 且 可 能 是 伟人 讨厌 的 ， 有 经 
验 的 C++ 程序 员 常 常 说 带 有 undefined behavior (未 定义 行为 ) 的 程序 can (能 ) 毁 掉 你 的 
辛苦 工作 的 成 果 。 这 是 真 的 : 一 个 带 有 undefined behavior (未 定义 行为 ) 的 程序 could (可 
以 ) 毁 掉 你 的 心血 。 只 不 过 可 能 性 不 太 大 。 更 可 能 的 是 那个 程序 的 表现 反复 无 常 ， 有 时 会 运 
行 正常 ， 有 了 时 会 彻底 完蛋 ， 还 有 时 会 产生 错误 的 结果 。 有 实力 的 C++ 程序 员 能 以 最 佳 状态 避 
FF undefined behavior (未 定义 行为 ) 。 本 书 中 ， 我 会 指出 许多 你 必须 要 注意 它 的 地 方 。 


另 一 个 可 能 把 从 其 它 语言 转 到 C++ 的 程序 员 搞 糊涂 的 术语 是 interface (接口 ) Java 和 
NET 的 语言 都 将 Interfaces (接口 ) 作为 一 种 语言 要 素 ， 但 是 在 C++ 中 没有 这 种 事 ， 但 是 在 
Item 31 讨论 了 如 何 模拟 它 。 当 我 使 用 术语 "interface" (接口 ) 时 ， 一 般 情况 下 我 说 的 是 一 个 
KAÉ signature (识别 特征 ) ， 是 一 个 class (#) 的 可 访问 元 素 (例如 ， 一 个 class (类 ) 
的 "public interface"，"protected interface"， 或 "private interface") ， 或 者 是 对 一 个 
template (模板 ) 的 type parameter (类 型 参数 ) 来 说 必须 合法 的 expressions (表达 式 ) 
(参见 Item 41) 。 也 就 是 说 ， 我 是 作为 一 个 相当 普通 的 设计 概念 来 谈论 interface (接口 ) 
的 。 


cient (客户 ) 是 使 用 你 写 的 代码 (一 般 是 interfaces (接口 ) ) 的 某 人 或 某 物 。 例 如 ， 一 个 
WA clients (客户 ) 就 是 它 的 使 用 者 : 调用 这 个 函数 〈 或 持 有 它 的 地 址 ) 的 代码 的 片段 以 
及 写 出 和 维护 这 样 的 代码 的 人 。class (类 ) XA template (模板 ) 的 clients (客户 ) 是 使 用 
这 个 class (类 ) 或 template (模板 ) 的 软件 的 部 件 ， 以 及 写 出 和 维护 那些 代码 的 程序 员 。 在 
讨论 clients (客户 ) 的 时 候 ， 我 一 般 指向 程序 员 ， 因 为 程序 员 会 被 困扰 和 误导 ， 或 者 因为 不 
好 的 interfaces (接口 ) 而 烦恼 。 但 他 们 写 的 代码 却 不 会 。 


你 也 许 不 习惯 于 为 clients (客户 ) 着 想 ， 但 是 我 会 用 大 量 的 时 间 试图 说 服 你 : 你 应 该 尽 你 所 

能 使 他 们 的 生活 更 轻松 。 记 住 ， 你 也 是 一 个 其 他 人 开发 的 软件 的 client (客户 ) 。 难 道 你 不 希 
望 那些 人 为 你 把 事情 弄 得 轻松 些 吗 ? 除 此 之 外 ， 你 几乎 肯定 会 在 某 个 时 候 发 现 你 自己 处 在 了 

你 自己 的 client (BP) 的 位 置 上 (也 就 是 说 ， 使 用 你 写 的 代码 ) ， 而 这 个 时 候 ， 你 会 为 你 在 
开发 你 的 interfaces (HO) 时 在 头脑 中 保持 了 对 client (客户 ) 的 关心 而 感到 高 闪 。 


ADH, KR HEE functions (函数 ) 和 function templates (ARR) 之 间 以 及 
classes (类 ) 和 class templates (类 模板 ) 之 间 的 区 别 。 那 是 因为 对 其 中 一 个 确定 的 事 对 另 
一 个 常常 也 可 以 确定 。 如 果 不 是 这 样 ， 我 会 区 别 对 待 classes (类 ) , functions (WR) ， 以 
及 由 classes (#) 和 functions (aX) 产生 的 templates (模板 ) 。 


在 代码 注释 中 提 到 constructor (构造 函数 ) 和 destructors (WAR 时 ， 我 有 时 使 用 缩写 
形式 ctor 和 dtor。 


Naming Conventions (命名 惯例 ) 


我 试图 为 objects (对 象 ) ，classes (#) , functions (Ht) , templates (模板 ) 等 选择 
意味 深长 的 名 字 ， 但 是 在 我 的 某 些 名 字 后 面 的 含义 可 能 不 会 立即 显现 出 来 。 例 如 ， 我 特别 喜 
欢 的 两 个 parameter names (参数 名 字 ) 是 Ihs 和 rhs。 它 们 分 别 代 表 "left-hand side" 和 
"right-hand side"。 我 经 常用 它们 作为 实现 binary operators (二 元 运算 符 ) HWM (GIA, 
operator== 和 operator*) 的 parameter names (参数 名 字 ) 。 例 如 ， 如 果 a 和 b 是 代表 有 理 
AA objects (对 象 ) , MAAR Rational objects (对 象 ) 能 通过 一 个 non-member (JERK 
A) 的 operator 函数 相 乘 (ltem 24 中 解释 的 很 可 能 就 是 这 种 情况 ) ， 表 达 式 


antip 


与 画 数 调用 


operator*(a,b) 


就 是 等 价 的 。 
在 Item 24 中 ， 我 这 样 声明 operator : 


const Rational operator*(const Rational& lhs, const Rational& rhs); 


{RA LAS EI, left-hand operand (左手 操作 数 ) a 在 函数 内 部 以 Ihs 的 面目 出 现 ， 而 right- 
hand operand (右手 操作 数 ) b 以 rhs 的 面目 出 现 。 


对 于 member functions (Ax A IŽ) , left-hand argument (左手 参数 ) 表现 为 this 

pointer (this 指针 ) ， 所 以 有 时 候 我 单独 使 用 parameter name (参数 名 字 ) rhs。 你 可 能 
经 在 第 5 页 中 某 些 Widget 的 member functions (AX A BAX) 的 declarations (声明 ) (AX 
介绍 copy constructor (拷贝 构造 范 数 ) 的 那 一 段 中 的 例子 一 一 译 者 注 ) 中 注意 到 了 这 一 点 。 
这 一 点 提醒 了 我 。 我 经 常 在 示例 中 使 用 Widget class (类 ) 。"Widget" 并 不 意味 着 什么 未 

西 。 它 仅仅 是 在 我 需要 一 个 示例 类 的 名 字 的 时 候 不 时 地 使 用 一 下 的 名 字 。 它 和 GUI 工具 包 中 
的 widgets 没有 任何 关系 。 


我 经 常 遵循 这 个 规则 为 pointers (指针 ) 命名 : 一 个 指向 type (类 型 ) TAH object (对 象 ) 的 
pointer (指针 ) EA pt, "pointer to T"。 以 下 是 例子 : 


Widget *pw; // pw = ptr to Widget 
class Airplane; 

Airplane *pa; // pa = ptr to Airplane 
class GameCharacter; 


GameCharacter *pgc; // pgc = ptr to GameCharacter 


我 对 references (引用 ) 使 用 类 似 的 惯例 : rw 可 以 认为 是 一 个 reference to a 


Widget 〈《 引 向 一 个 Widget 的 引用 ) ， 而 ra 是 一 个 reference to an Airplane ( 引 向 一 个 
Airplane 的 引用 ) 。 


在 讨论 member functions (AK AR) 的 时 候 我 偶尔 会 使 用 名 字 mf 
Threading Considerations (对 线程 的 考虑 ) 


作为 一 种 语言 ，C++ 没有 threads (线程 ) 的 概念 一 一 实际 上 ， 是 没有 任何 一 种 
concurrency (并 发 ) 的 概念 。 对 于 C++ 标准 库 也 是 同样 如 此 。 就 C++ 涉及 的 范围 而 言 ， 
multithreaded programs (多 线程 编程 ) 并 不 存在 。 





而 且 至 今 它们 依然 如 此 。 我 致力 于 让 此 书 基于 标准 的 ， 可 移植 的 C++， 但 我 也 不 能 对 thread 
safety (线程 安全 ) 已 成 为 很 多 程序 员 所 面临 的 一 个 问题 的 事实 视而不见 。 我 对 付 这 个 标准 
C++ 和 现实 之 间 的 裂痕 的 方法 就 是 指出 某 个 C++ constructs (结构 成 分 ) 以 我 的 分 析 很 可 能 
在 threaded environment (线程 环境 ) 中 引起 问题 的 地 方 。 这 样 不 但 不 会 使 本 书 成 为 一 本 
multithreaded programming with C++ (用 C++ 进行 多 线程 编程 ) 的 书 。 反 而 ， 它 更 会 使 本 书 
在 相当 程度 上 成 为 这 样 一 本 C++ 编程 的 书 : 将 自己 在 很 大 程度 上 限制 于 single-threaded (# 
线程 ) 思路， 承认 multithreading (多 线程 ) 的 存在 ， 并 试图 指出 有 线程 意识 的 程序 员 需 要 特 
别 留心 评估 我 提供 的 建议 的 地 方 。 


如 果 你 不 熟悉 multithreading (SAE) 或 者 不 必 为 此 担心 ， 你 可 以 忽略 我 关于 线程 的 讨论 。 
如 果 你 正在 编写 一 个 多 线程 的 点 用 或 库 ， 无 论 如 何 ， 请 记 住 我 的 评注 和 并 将 它 作为 你 使 用 
C++ 时 需要 致力 去 解决 的 问题 的 起 点 。 


TR1 和 Boost 


你 会 发 现 提 及 TR1 和 Boost 的 地 方 通 及 全 书 。 它 们 每 一 个 都 有 一 个 专门 的 ltem 在 某 些 细节 

上 进行 描述 (Item 54 是 TR1，ltem 55 Boost) ， 但 是 ， 不 幸 的 是 ， 这 些 ltem 在 全 书 的 最 
后 。 (他 们 在 那里 是 因为 那样 更 好 一 些 ， 我 确实 试 过 很 多 其 它 的 地 方 。) 如 果 你 愿意 ， 你 现 

在 就 可 以 翻 开 并 阅读 那些 llem， 但 是 如 果 你 更 喜欢 从 本 书 的 起 始 处 而 不 是 结尾 处 开始 ， 以 下 

摘要 会 对 你 有 所 帮助 : 


e TR1 ("Technical Report 1") 是 被 加 入 C++ 标准 库 的 新 机 能 的 specification (规格 说 明 
书 ) 。 这 些 机 能 以 新 的 class (类 ) 和 function templates (函数 模板 ) 的 形式 提供 了 诸 
如 hash tables ( 哈 希 表 ) ，reference-counting smart pointers (引用 计数 智能 指针 ) ， 


regular expressions (正则 表达 式 ) ， 等 等 。 所 有 的 TR1 组 件 都 位 于 族 套 在 namespace 
std 内 部 的 namespace tr1 A. 


Boost 是 一 个 组 织 和 一 个 网 站 (http://boost.org) 提供 的 可 移植 的 ， 经 过 同行 评审 的 ， 开 源 
的 C++ 库 。 大 多 数 TR1 机 能 都 基于 Boost 的 工作 ， 而 且 直 到 编译 器 厂商 在 他 们 的 C++ 

库 发 行 版 中 包含 TR1 之 前 ，Boost 网 站 很 可 能 会 保持 开发 者 寻找 TR1 实现 的 第 一 站 的 地 
fii, Boost 提供 的 东西 比 用 于 TR1 的 更 多 ， 无 论 如 何 ， 在 很 多 情况 下 ， 它 还 是 值得 去 了 

解 一 下 的 。 


Item 1: 将 C++ #4 federation of languages ( 语 
SKA) 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


最 初 ，C++ 仅仅 是 在 C 的 基础 上 附加 了 一 些 object-oriented (面向 对 象 ) 的 特性 。C++ 最 初 
的 名 称 "C with Classes" 就 非常 直观 地 表现 了 这 一 点 。 


作为 一 个 语言 的 成 熟 过 程 ，C++ 的 成 长 大 胆 而 充满 冒险 ， 它 吸收 的 思想 ， 特 性 ， 以 至 于 编程 
策略 与 C with Classes 越 来 越 不 同 。exceptions (异常 ) 要 求 不 同 的 建构 功能 的 途径 (BR 
Item 29) , templates (模板 ) 将 设计 思想 提升 到 新 的 高 度 (参见 ltem 41) ， 而 STL 定义 了 
一 条 前 所 未 见 的 通 向 扩展 性 的 道路 。 





今天 的 C++ 已 经 成 为 一 个 multiparadigm programming language (多 范式 的 编程 语言 ) ， 一 
MEHET procedural (过 程 化 ) , object-oriented (面向 对 象 ) functional (RAE) , 
generic (322!) 以 及 metaprogramming (元 编程 )》 特 性 的 联合 体 。 这 些 能 力 和 弹性 使 C++ 
成 为 无 可 匹敌 的 工具 ， 但 也 引起 了 一 些 混乱 。 所 有 的 "proper usage" (惯用 法 ) 规则 似乎 都 有 
例外 。 我 们 该 如 何 认 识 这 样 一 个 语言 ? 


最 简单 的 方法 是 不 要 将 C++ 视 为 一 个 单一 的 语言 ， 而 是 一 个 亲族 的 语言 的 federation (KA 
体 ) 。 在 每 一 个 特定 的 sublanguage (F48) 中 ， 它 的 特性 趋向 于 直截了当 ， 简 单 易 记 。 
但 你 从 一 个 sublanguage (F48) 转 到 另外 一 个 ， 它 的 规则 也 许 会 发 生变 化 。 为 了 感受 
C++， 你 必须 将 它 的 主要 的 sublanguages ( 子 语言 ) 组 织 到 一 起 。 幸 运 的 是 ， 它 只 有 4 个 : 


e C 一 一 上 归根 结 底 ，C+t+ 依然 是 基于 CH. blocks (模块 ) , statements (语句 ) , 
preprocessor ( 预 处 理 器 ) ，built-in datatypes (内 建 数据 类 型 ) ，arrays (数组 ) , 
pointers (指针 ) 等 等 ， 全 都 来 自 于 C。 在 很 多 方面 。C++ 提出 了 上 比 相应 的 C 版 本 更 高 
级 的 解决 问题 的 方法 (例如 ， 参 见 ltem 2 (选择 preprocessor 〈 预 处 理 器 ) ) 和 13 (使 
用 objects (对 象 ) 管理 resources (资源 ) ) ) ， 但 是 ， 当 你 发 现 你 自己 工作 在 C++ 的 
C 部 分 时 ，effective programming (高 效 编程 ) 的 规则 表现 了 C 的 诸多 限制 范围 : 没有 
templates (模板 ) ， 没 有 exceptions (3%) ， 没 有 overloading (E8) SS. 


e Object-Oriented C++ C++ 的 这 部 分 就 是 C with Classes 涉及 到 的 全 部 : 
classes (类 ) (ih Mis NAAT HR) , encapsulation (封装 ) , inheritance (4k 
7K) , polymorphism (4%) , virtual functions (dynamic binding) (虚拟 函数 (动态 绑 
E) ) 等 。C++ 的 这 一 部 分 直接 适用 于 object-oriented design (面向 对 象 设 计 ) 的 经 典 
规则 。 








e Template C++ 这 是 C++ 的 generic programming 〈 泛 型 编程 ) 部 分 ， 大 多 数 程序 员 
对 此 都 缺乏 经 验 。template (模板 ) HZ EDER C++， 而 且 好 的 编程 规则 中 包含 特殊 
的 template-only (模板 专用 ) 条 款 已 不 再 不 同 寻常 (参见 Item 46 通过 调用 template 
functions (模板 函数 ) 简化 type conversions (类 型 转换 ) ) 。 实 际 上 ，templates ( 模 
AR) 极为 强大 ， 它 提供 了 一 种 全 新 的 programming paradigm (编程 范式 ) 一 template 
metaprogramming (TMP) (模板 元 编程 ) . Item 48 提供 了 一 个 TMP 的 概述 ， 但 是 ， 除 
非 你 是 一 个 hard-core template junkie 〈 和 死心 塌 地 的 模板 瘾 君子 ) ， 否 则 你 不 需 在 此 咒 
心 ，TMP 的 规则 对 主流 的 C++ 编程 少 有 影响 。 


e STL—— STL 是 一 个 template library 〈 模 板 库 ) ， 但 它 一 个 非常 特殊 的 template 
library (RARE) 。 它 将 containers (容器 ) , iterators (迭代 器 ) , algorithms (算法 ) 
和 function objects ( 范 数 对 象 ) 非 常 优雅 地 整合 在 一 起 ， 但 是 。templates (模板 ) 和 
libraries ( 库 ) 也 可 以 围绕 其 它 的 想法 建立 起 来 。STL 有 很 多 独特 的 处 事 方 法 ， 当 你 和 
STL 一 起 工作 ， 你 需要 遵循 它 的 规则 。 


在 头脑 中 保持 这 四 种 sublanguages ( 子 语言 ) ， 当 你 从 一 种 sublanguage ( 子 语言 ) 转 到 另 
一 种 时 ， 为 了 高 效 编程 你 需要 改变 你 的 策略 ， 不 要 吃惊 你 遭遇 到 的 情景 。 例 如 ， 使 用 built- 
in (内 建 ) (也 就 是 说 ，C-like (类 C 的 ) ) 类 型 时 ，pass-by-value (4444) 通常 比 pass- 
by-reference ( 传 引 用 ) 更 高 效 ， 但 是 当 你 从 C++ 的 C 部 分 转 到 Object-Oriented C++ (面向 
对 象 C++) , user-defined constructors (FA? B EŒ Mis EHRX) 和 destructors (ERZ 
意味 着 ， 通 常情 况 下 ， 更 好 的 做 法 是 pass-by-reference-to-const ( 传 引 用 给 const) 。 在 
Template C++ 中 工作 时 ， 这 一 点 更 加 重要 ， 因 为 ， 在 这 种 情况 下 ， 你 甚至 不 知道 你 的 操作 涉 
及 到 的 object (sts) 的 类 型 。 然 而 ， 当 你 进入 STL， 你 知道 iterators (4085) 和 function 
objects (FR xtR) LAC 的 pointers (指针 ) 为 原型 ， 对 于 STL 中 的 iterators GES) 和 
function objects (Hu) , HBA C 中 的 pass-by-value ( 传 值 ) 规则 又 重新 生效 。 (X 
于 选择 parameter-passing (参数 传递 ) 方式 的 全 部 细节 ， 参 见 ltem 20。) 


C++ 不 是 使 用 一 套 规则 的 单一 语言 ， 而 是 federation of four sublanguages (四 种 子 语言 的 联 
合体 ) ， 每 一 种 都 有 各 自 的 规则 。 在 头脑 中 保持 这 些 sublanguages 〈 子 语言 ) ， 你 会 发 现 对 
C++ 的 理解 会 容易 得 多 。 


Things to Remember 


e effective C++ programming 〈 高 效 C++ 编程 ) 规则 的 变化 ， 依 赖 于 你 使 用 C++ 的 哪 一 个 
部 分 。 


Item 2: FA consts, enums 和 inlines 取代 
#defines 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


这 个 Item 改名 为 “用 compiler (编译 器 ) 取代 preprocessor ( 预 处 理 器 ) "也 许 更 好 一 些 ， 
为 #define 根本 就 没有 被 看 作 是 语言 本 身 的 一 部 分 。 这 是 它 很 多 问题 中 的 一 个 。 当 你 像 下 面 这 
样 做 : 


#define ASPECT_RATIO 1.653 


compiler (编译 器 ) 也 许 根本 就 没有 看 见 这 个 符号 名 ASPECT_RATIO, fE compiler (编译 
器 ) 得 到 源 代码 之 前 ， 这 个 名 字 就 已 经 被 preprocessor ( 预 处 理 器 ) 消除 了 。 结 果 ， 名 字 
ASPECT_RATIO 可 能 就 没有 被 加 入 symbol table (符号 表 ) 。 如 果 在 编译 的 时 候 ， 发 现 一 个 
constant (常量 ) 使 用 的 错误 ， 你 可 能 会 陷入 混乱 之 中 ， 因 为 错误 信息 中 很 可 能 用 1.653 取代 
了 ASPECT_RATIO。 如 果 ，ASPECT_RATIO 不 是 你 写 的 ， 而 是 在 头 文件 中 定义 的 ， 你 可 能 
会 对 1.653 的 出 处 毫 无 头绪 ， 你 还 会 为 了 跟踪 它 而 浪费 时 间 。 在 symbolic debugger (符号 调 
试 器 ) 中 也 会 遇 到 同样 的 问题 ， 同 样 是 因为 这 个 名 字 可 能 并 没有 被 加 入 symbol table (符号 
表 ) 。 


解决 方案 是 用 constant (常量 ) 来 取代 macro (B) 


const double AspectRatio = 1.653; // uppercase names are usually for 
// macros, hence the name change 


作为 一 个 language constant (语言 层面 上 的 常量 ) ，AspectRatio # compilers (编译 器 ) 5A 
确 识 别 并 确实 加 入 symbol table (符号 表 ) 。 另外， 对 于 floating point constant 〈 浮 点 常量 
(比如 本 例 ) 来 说 ， 使 用 constant (常量 ) 比 使 用 #define 能 产生 更 小 的 代码 。 这 是 因为 
preprocessor ( 预 处 理 器 ) 盲目 地 用 1.653 置换 macro name ( 宏 名 字 ) ASPECT_RATIO, 
导致 你 的 object code (目标 代码 ) 中 存在 多 个 1.653 的 拷贝 ， 如 果 使 用 constant (常量 
AspectRatio， 就 绝 不 会 产生 多 于 一 个 的 拷贝 。 


用 constant (常量 ) 代替 #defines 时 ， 有 两 个 特殊 情况 值得 提出 。 首 先是 关于 constant 
pointers (常量 指针 ) 的 定义 。 因 为 constant definitions (常量 定义 ) 通常 被 放 在 header 
fies ( 头 文件 ) 中 (这样 它 们 就 可 以 被 包含 在 多 个 source files ( 源 文件 ) 中 ) ， 除 了 


pointer (指针 ) 指向 的 目标 是 常量 外 ，pointer (指针 ) 本 身 被 声明 为 const 更 加 重要 。 例 
如 ， 在 头 文件 中 定义 一 个 constant char*-based string (基于 char 的 字符 串 常量 ) 时 ， 你 必 
须 写 两 次 const : 


const char * const authorName = "Scott Meyers"; 


对 于 const (特别 是 与 pointers (指针 ) 相 结 合 时 ) 的 意义 和 使 用 的 完整 讨论 ， 请 参见 tem 
3。 然 而 在 此 值 的 一 提 的 是 ，string objects 〈 对 象 ) 通常 比 它 的 char*-based (基于 char*) 的 
祖先 更 可 取 ， 所 以 ， 更 好 的 authorName 的 定义 方式 如 下 : 


const std::string authorName("Scott Meyers"); 


第 二 个 特殊 情况 涉及 到 class-specific constants (类 属 (类 内 部 专用 的 ) 常量 ) 。 为 了 将 一 个 
constant (常量 ) 的 作用 范围 限制 在 一 个 class (类 ) 内 ， 你 必须 将 它 作 为 一 个 类 的 

member (RA) ， 而 且 为 了 确保 它 最 多 只 有 一 个 constant (常量 ) 拷贝 ， 你 还 必须 把 它 声明 
为 一 个 static member (静态 成 员 ) 。 


class GamePlayer { 


private: 
static const int NumTurns = 5; // constant declaration 
int scores[NumTurns]; // use of constant 

~ 


你 从 上 面 只 看 到 了 NumTurns 的 declaration (8A) ， 而 不 是 definition (定义 ) 。 通 常 ， 
C++ 要 求 你 为 你 使 用 的 任何 东西 都 提供 一 个 definition (EX) ， 但 是 一 个 static (静态 ) 的 
integral type (ÆR) (例如 : integers ( 整 型 ) ，chars，bools) 的 class-specific 
constants (类 属 常量 ) 是 一 个 例外 。 只 要 你 不 去 取得 它们 的 address (地 址 ) ， 你 可 以 只 声 
明 并 使 用 它 ， 而 不 提供 它 的 definition (定义 ) 。 如 果 你 要 取得 一 个 class constant (类 属 常 
=) 的 address (地 址 ) ， 或 者 你 使 用 的 compiler (编译 器 ) 在 你 没有 取得 address (地 址 ) 
时 也 不 正确 地 要 求 definition (定义 ) 的 话 ， 你 可 以 提供 如 下 这 样 一 个 独立 的 definition CE 
SE 


const int GamePlayer: :NumTurns,; // definition of NumTurns; see 
// below for why no value is given 


你 应 该 把 它 放 在 一 个 implementation file (实现 文件 ) 而 非 header file ( 头 文件 ) 中 。 因 为 
class constants (类 属 常量 ) 的 initial value (初始 值 ) 在 声明 时 已 经 提供 (例如 : NumTurns 
在 定义 时 被 初始 化 为 5) ， 因 此 在 定义 处 允许 没有 initial value (初始 值 ) 。 


注意 ， 顺 便 提 一 下 ， 没 有 办 法 使 用 #define 来 创建 一 个 class-specific constant (类 属 常 

=) ， 因 为 #defines 不 考虑 scope (作用 范围 ) 。 一 旦 一 个 macro( 宏 ) 被 定义 ， 它 将 大 范 
影响 你 的 代码 (除非 在 后 面 某 处 存在 #undefed) 。 这 就 意味 着 ，#defines 不 仅 不 能 用 于 

class-specific constants (类 属 常量 ) ， 而 且 不 能 提供 任何 形式 的 encapsulation (封装 ) , 

也 就 是 说 ， 没 有 类 似 "private" (私有 ) #define 的 东西 。 当 然 ，const data members (const 

数据 成 员 ) 是 能 够 被 封装 的 ，NumTurns 就 是 如 此 。 


比较 老 的 compilers (编译 器 ) 可 能 不 接受 上 面 的 语法 ， 因 为 它 习 惯 于 将 一 个 static class 
member (静态 类 成 员 ) 在 声明 时 就 获得 initial value (初始 值 ) 视 为 非法 。 而 且 ，in-class 
initialization (类 内 初始 化 ) 仅仅 对 于 integral types (ÆR) 和 constants (常量 ) 才 被 允 
许 。 如 果 上 述 语法 不 能 使 用 ， 你 可 以 将 initial value (初始 值 ) 放 在 定义 处 : 


class CostEstimate { 


private: 
static const double FudgeFactor; // declaration of static class 
aot // constant; goes in header file 
}; 
const double // definition of static class 


CostEstimate: :FudgeFactor = 1.35; // constant; goes in impl. file 


这 就 是 你 所 要 做 的 全 部 。 仅 有 的 例外 是 当 在 类 的 编译 期 需要 value of a class constant (一 个 
类 属 常 量 的 值 ) 的 情况 ， 例 如 前 面 在 声明 array (数组 ) GamePlayer::scores 时 

(compilers (编译 器 ) 必须 在 编译 期 知道 array (数组 ) 的 size (大 小 ) ) 。 如 果 
compilers (编译 器 ) (不 正确 地 ) 禁止 这 种 关于 static integral class constants (静态 整 型 族 
类 属 常量 ) 的 initial values (初始 值 ) 的 使 用 方法 的 in-class specification (规范 ) ， 一 个 可 
接受 的 替代 方案 被 亲切 地 (并非 轻 成 地) 昵称 为 "the enum hack"。 这 项 技术 获得 以 下 事实 的 
支持 : 一 个 enumerated type ( 枚 举 类 型 ) 的 值 可 以 用 在 一 个 需要 ints 的 地 方 。 所 以 
GamePlayer 可 以 被 如 下 定义 : 


class GamePlayer { 


private: 
enum { NumTurns = 5 }; // “the enum hack" - makes 
// NumTurns a symbolic name for 5 
int scores[NumTurns]; // fine 
J; 


the enum hack 有 几 个 值得 被 人 所 知 的 原因 。 首 先 ，the enum hack 的 行为 在 几 个 方面 上 更 像 
一 个 #define 而 不 是 const， 而 有 时 这 正 是 你 所 需要 的 。 例 如 : 可 以 合法 地 取得 一 个 const 的 
address (地 址 ) ， 但 不 能 合法 地 取得 一 个 enum 的 address (地 址 ) ， 这 正 像 同样 不 能 合 

地 取得 一 个 #define 的 address (HEHE) 。 如 果 你 不 希望 人 们 得 到 你 的 integral constants 〈 整 
型 族 常量 ) 的 pointer (指针 ) 或 reference (引用 ) , enum ( 枚 举 ) 就 是 强制 约束 这 一 点 的 


好 方法 。 (关于 更 多 的 通过 编码 的 方法 强制 执行 设计 约束 的 方法 ， 参 见 ltem 18. ) 同样 ， 使 
用 好 的 compilers (编译 器 ) TAA integral types ( 整 型 族 类 型 ) 的 const objects (const 对 
象 ) 分 配 多 余 的 内 存 (除非 你 创建 了 这 个 对 象 的 指针 或 引用 ) ， 即 使 拖泥带水 的 

compilers (编译 器 ) 乐意 ， 你 也 决 不 会 乐意 为 这 样 的 objects 〈 对 象 ) 分 配 多 余 的 内 存 。 像 
#defines 和 enums (MA) 就 绝 不 会 导致 这 种 unnecessary memory allocation (不 必要 的 内 
存 分 配 ) 。 


需要 知道 the enum hack 的 第 二 个 理由 是 纯粹 实用 主义 的 ， 大 量 的 代码 在 使 用 它 ， 所 以 当 你 
看 到 它 时 ， 你 要 认识 它 。 实 际 上 ，the enum hack 是 template metaprogramming (模板 元 编 
程 ) 的 一 项 基本 技术 (参见 Item 48) 。 


回 到 preprocessor ( 预 处 理 器 ) 上 来 ，#define 指 今 的 另 一 个 普通 的 (不 好 的 ) 用 法 是 实现 看 
来 像 画 数 ， 但 不 会 引起 一 个 函数 调用 的 开销 的 macros ( 宏 ) 。 以 下 是 一 个 用 较 大 的 宏 参 数 调 
用 函数 ff 的 macro (#) 


// call f with the maximum of a and b 


#define CALL_WITH_MAX(a, b) f((a) &gt; (b) ? (a) : (b)) 


这 样 的 macro (B) 有 数 不 清 的 缺点 ， 想 起 来 就 让 人 头疼 。 


无 论 何 时 ， 你 写 这 样 一 个 macro (B) ， 都 必须 记 住 为 macro body (Bik) 中 所 有 的 
arguments (参数 ) 加 上 括号 。 否 则 ， 当 其 他 人 在 表达 式 中 调用 了 你 的 macro ( 宏 ) ， 你 将 陷 
入 麻烦 。 但 是 ， 即 使 你 确实 做 到 了 这 一 点 ， 你 还 是 会 看 到 意 想不到 的 事情 发 生 : 


int a = 5, b = @; 
CALL_WITH_MAX(++a, b); // a is incremented twice 


CALL_WITH_MAX(++a, b+10); // a is incremented once 


这 里 ， 调 用 f 之 前 a 递增 的 次 数 取决 于 它 和 什么 进行 比较 | 


幸运 的 是 ， 你 并 不 是 必须 要 和 这 样 不 知 所 云 的 东西 打交道 。 你 可 以 通过 一 个 inline 
function (AE) 的 template (模板 ) 来 获得 macro (B) 的 效率 ， 以 及 完全 可 预测 的 行 
为 和 常规 范 数 的 类 型 安全 (参见 Item 30) 


template<typename T> // because we don't 

inline void callWithMax(const T& a, const T& b) // know what T is, we 

{ // pass by reference-to- 
f(ia>b?a: b); // const - see Item 20 


这 个 template (模板 ) 产生 一 组 函数 ， 每 一 个 获得 两 个 相同 类 型 的 对 象 并 使 用 其 中 较 大 的 一 
个 调用 f 这 样 就 不 需要 为 函数 体内 部 的 参数 加 上 括号 ， 也 不 需要 担心 多 余 的 参数 解析 次 数 ， 
等 等 。 此 外 ， 因 为 callWithMax 是 一 个 真正 的 函数 ， 它 遵循 画 数 的 作用 范围 和 访问 规则 。 例 
如 ， 谈 论 一 个 类 的 私有 的 inline function (AREKO 会 获得 正确 的 理解 ， 但 是 用 

macro (%) 就 无 法 做 到 这 一 点 。 

为 了 得 到 consts，enums 和 inlines 的 可 用 性 ， 你 需要 尽量 减少 preprocessor (fi tess) 
(特别 是 #define) 的 使 用 ， 但 还 不 能 完全 消除 。##include 依然 是 基本 要 素 ， 而 #ifdef/#ifndef 
也 继续 扮演 着 重要 的 角色 。 现 在 还 不 是 让 preprocessor ( 预 处 理 器 ) 完全 退休 的 时 间 ， 但 你 
应 该 给 它 漫长 而 频繁 的 假期 。 


Things to Remember 


e 对 于 simple constants (简单 常量 ) ， 用 const objects (const 对 象 ) 或 enums ( 枚 举 ) 
取代 #defines. 


e 对 于 function-like macros (# (EAI) ， 用 inline functions (Aa) 取代 
#defines. 


Item 3: RARER const 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


关于 const 的 一 件 美妙 的 事情 是 它 允 许 你 指定 一 种 semantice (语义 上 的 ) 约束 : 一 个 特定 的 
object (对 象 ) 不 应 该 被 修改 。 而 compilers (编译 器 ) 将 执行 这 一 约束 。 它 允许 你 通知 
compilers (编译 器 ) 和 其 他 程序 员 ， 某 个 值 应 该 保持 不 变 。 如 果 确 实 如 此 ， 你 就 点 该 明确 地 
表示 出 来 ， 因 为 这 样 一 来 ， 你 就 可 以 谋求 compilers (编译 器 ) 的 帮助 ， 确 保 这 个 值 不 会 被 改 
keyword (关键 字 ) const 非常 多 才 多 艺 。 在 classes (类 ) 的 外 部 ， 你 可 以 将 它 用 于 

global (全 局 ) 或 namespace (命名 空间 ) 范围 的 constants (常量 ) (参见 ltem 2) ， 以 及 
那些 在 file (文件 ) 、function (ERX) 或 block (模块 ) scope (范围 ) 内 被 声明 为 

static (HA) 的 对 象 。 在 classes (类 ) 的 内 部 ， 你 可 以 将 它 用 于 static (静态 ) 和 non- 
static 〈 非 静态 ) data members (数据 成 员 ) 上 。 对 于 pointers (指针 ) ， 你 可 以 指定 这 个 
pointer (指针 ) 本 身 是 const， 或 者 它 所 指向 的 数据 是 const， 或 者 两 者 都 是 ， 或 者 都 不 是 : 


char greeting[] = "Hello"; 


char *p = greeting; // non-const pointer, 
// non-const data 


const char *p = greeting; // non-const pointer, 
// const data 


char * const p = greeting; // const pointer, 
// non-const data 


const char * const p = greeting; // const pointer, 
// const data 


这 样 的 语法 本 身 其 实 并 不 像 表 面 上 那样 反复 无 常 。 如 果 const 出 现在 星 号 左边 ， 则 指针 
pointed to (指向 ) 的 内 容 为 constant (常量 ) ; 如 果 const 出 现在 星 号 右边 ， 则 pointer 
itself (指针 自身 ) 为 constant (常量 ) ; 如 果 const 出 现在 星 号 两 边 ， 则 两 者 都 为 
constant (常量 ) 。 


当 指 针 指 向 的 内 容 为 constant (常量 ) 时 ， 一 些 人 将 const 放 在 类 型 之 前 ， 另 一 些 人 将 它 放 


在 类 型 之 后 星 号 之 前 。 两 者 在 意义 上 并 没有 区 别 ， 所 以 ， 如 下 两 个 函数 具有 相同 的 parameter 
type 〈 参 数 类 型 ) 


void fi(const Widget *pw); // f1 takes a pointer to a 
// constant Widget object 


void f2(Widget const *pw); // so does f2 


因为 它们 都 存在 于 实际 的 代码 中 ， 你 应 该 习惯 于 这 两 种 形式 。 


STL iterators (和 迭代 器 ) 以 pointers (指针 ) 为 原型 ， 所 以 一 个 iterator 在 行为 上 非常 类 似 于 
一 个 T* pointer (指针 ) 。 声 明 一 个 iterator 4 const 就 类 似 于 声明 一 个 pointer (指针 ) 为 
const (也 就 是 说 ， 声 明 一 个 T* const pointer (指针 ) ) : 不 能 将 这 个 iterator 指向 另外 一 件 
不 同 的 东西 ， 但 是 它 所 指向 的 东西 本 身 可 以 变化 。 如 果 你 要 一 个 iterator 指向 一 个 不 能 变化 的 
东西 (也 就 是 一 个 const T* pointer (指针 ) 的 STL 对 等 物 ) ， 你 需要 一 个 const_iterator : 


std::vector<int> vec; 


const std::vector<int>::iterator iter = // iter acts like a T* const 
vec. begin(); 
*iter = 10; // OK, changes what iter points to 
++iter; // error! iter is const 
std: :vector<int>::const_iterator cIter = // cIter acts like a const T* 
vec. begin(); 
*cIter = 10; // error! *cIter is const 
++cIter; // fine, changes citer 


xt const 最 强 有 力 的 用 法 来 自 于 它 在 function declarations (HARA) 中 的 应 用 。 在 一 个 
function declaration (HUPA) 中 ，const a MARRA return value (返回 值 ) E, tE 
可 以 用 在 个 别 的 parameters (参数 ) 上 ， 对 于 member functions (RAW) ， 还 可 以 用 于 
整个 函数 。 


NKRA constant value (常量 值 ) ， 常 常 可 以 在 不 放弃 安全 和 效率 的 前 提 下 尽 可 能 
减少 客户 的 错误 造成 的 影响 。 例 如 ， 考 虑 在 ltem 24 中 考察 的 rational numbers (有 理 数 ) 的 
operator EX EXE FAA, 


class Rational { ... }; 


const Rational operator*(const Rational& lhs, const Rational& rhs); 


很 多 第 一 次 看 到 这 些 的 程序 员 会 不 以 为 然 。 为 什么 operator 的 结果 应 该 是 一 个 const 
object (R) ? 因为 如 果 它 不 是 ， 客 户 就 可 以 犯 下 如 此 暴行 : 


Rational a, b, c; 


(a * b) = c; // invoke operator= on the 
// result of a*b! 


我 不 知道 为 什么 一 些 程序 员 要 为 两 个 数 的 乘积 赋值 ， 但 是 我 知道 很 多 程序 员 这 样 做 也 并 非 不 
称职 。 所 有 这 些 可 能 来 自 一 个 简单 的 输入 错误 〈 要 求 这 个 类 型 能 够 隐 式 转型 到 bool) 


if (a * b=c) ... // oops, meant to do a comparison! 


如 果 a 和 b 是 built-in type (内 建 类 型 ) ， 这 样 的 代码 显而易见 是 非法 的 。 一 个 好 的 user- 
defined types (用 户 自 定义 类 型 ) 的 特点 就 是 要 避免 与 built-ins (内 建 类 型 ) 毫 无 理由 的 不 和 
谐 (BR Item 18) ， 而 且 对 我 来 说 允许 给 两 个 数 的 乘积 赋值 看 上 去 正 是 之 无 理由 的 。 将 
operator 的 返回 值 声明 为 const 就 可 以 避免 这 一 点 ， 这 就 是 我 们 要 这 样 做 的 理由 。 


关于 const parameters (参数 ) 没什么 特别 新 鲜 之 处 一 一 它们 的 行为 就 像 local (局 部 ) 的 
const objects (对 象 ) ， 而 且 无 论 何 时 ， 只 要 你 能 ， 你 就 应 该 这 样 使 用 。 除 非 你 需要 改变 一 个 
parameter (参数 ) 或 local object (本 地 对 象 ) 的 能 力 ， 否 则 ， 确 保 将 它 声 明 为 const。 它 只 
需要 你 键入 六 个 字符 ， 就 能 将 你 从 我 们 刚刚 看 到 的 这 个 恼人 的 错误 中 拯救 出 来 : "我 想 键 人 
'=='， 但 我 意外 地 键入 了 '=". 





const member functions (const AK A EN 2X) 


member functions (AK A K) 被 声明 为 const 的 目的 是 标明 这 个 member functions (成 员 

函数 ) 可 能 会 被 const objects 〈 对 象 ) 调用 。 因 为 两 个 原因 ， 这 样 的 member functions (成 
AWM) 非常 重要 。 首 先 ， 它 使 一 个 class (类 ) 的 interface (接口 ) 更 容易 被 理解 。 知 道 哪 
个 函数 可 以 改变 object 〈 对 象 ) 而 哪个 不 可 以 是 很 重要 的 。 第 二 ， 它 们 可 以 和 const 

objects (对 象 ) 一 起 工作 。 因 为 ， 书 写 高 效 代 码 有 一 个 很 重要 的 方面 ， 就 像 Item 20 所 解释 

的 ， 提 升 一 个 C++ 程序 的 性 能 的 基本 方法 就 是 pass objects by reference-to-const (以 传 引 

用 给 const 的 方式 传递 一 个 对 象 ) 。 这 个 技术 只 有 在 const member functions (Ak A AR) 和 
作为 操作 结果 的 const-qualified objects (W const 修饰 的 对 象 ) 存在 时 才 是 可 行 的 。 


很 多 人 没有 注意 到 这 样 的 事实 ， 即 member functions (X A WA) 在 只 有 constness (常量 
性 ) 不 同时 是 可 以 被 overloaded (BH) 的 ， 但 这 是 C++ 的 一 个 重要 特性 。 考 虑 一 个 代表 文 
本 块 的 类 : 


class TextBlock { 


public: 
const char& operator[](std::size_t position) const // operator[] for 
{ return text[position]; } // const objects 
char& operator[](std::size_t position) // operator[] for 
{ return text[position]; } // non-const objects 
private: 
std::string text; 


}; 


TextBlock 的 operator[ls 可 能 会 这 样 使 用 : 


TextBlock tb("Hello"); 
std::cout << tb[0]; // calls non-const 
// TextBlock: :operator[] 
const TextBlock ctb("World"); 
std::cout << ctb[0]; // calls const TextBlock::operator[] 


顺便 提 一 下 ，const objects (xt) 在 实际 程序 中 最 经 常 出 现 的 是 作为 这 样 一 个 操作 的 结 
passed by pointer- or reference-to-const (以 传 指针 或 者 引用 给 const 的 方式 传递 ) 。 上 面 的 
ctb 的 例子 是 人 工 假 造 的 。 下 面 这 个 例子 更 真实 一 些 : 


void print(const TextBlock& ctb) // in this function, ctb is const 
std::cout << ctb[0]; // calls const TextBlock::operator[] 
} 
通过 overloading (2) operator{], 给 不 同 的 版 本 不 同 的 返回 类 型 ， 你 能 对 const 和 


non-const 的 TextBlocks 做 不 同 的 操 


std::cout << tb[0]; // fine — reading a 
// non-const TextBlock 


tb[0] = 'x'; // fine — writing a 
// non-const TextBlock 


std::cout << ctb[0]; // fine — reading a 
// const TextBlock 


ctb[0] = 'x'; // error! — writing a 
// const TextBlock 


请 注意 这 里 的 错误 只 与 被 调用 的 operator[] 的 return type (返回 类 型 ) 有 关 ， 而 调用 
operator[] 本 身 总 是 正确 的 。 错 误 出 现在 企图 为 const char& 赋值 的 时 候 ， 因 为 它 是 const 版 
本 的 operator[] 的 return type (返回 类 型 ) 。 


再 请 注意 non-const 版 本 的 operator[] 的 return type (返回 ae 是 reference to a char (一 
个 char 的 引用 ) 而 不 是 一 个 char 本 身 。 如 果 operator[] 只 是 返回 一 个 简单 的 char， 下 面 的 
语句 将 无 法 编译 : 


tb[0] = 'x'; 


因为 改变 一 个 返回 built-in type (内 建 类 型 ) 的 函数 的 返回 值 总 是 非法 的 。 即 使 它 合 法 ，C++ 
returns ve by value 〈 以 传 值 方式 返回 对 象 ) 这 一 事实 (参见 nem 20) 也 意味 着 被 改变 
的 是 tb.text[0] 的 一 个 copy (A) ， 而 不 是 tb.text[0] 自己 ， 这 不 会 是 你 想 要 的 行为 。 


让 我 们 为 哲学 留 一 点 时 间 。 看 看 一 个 member function (ak AWA) 是 const 意味 着 什么 ?有 
2 个 主要 的 概念 : bitwise constness (二 进 制 位 常量 性 ) (也 称 为 physical constness (物理 
量 性 ) ) 和 logical constness (逻辑 常量 性 ) 。 


bitwise (二 进 制 位 ) const 派别 坚持 认为 ， 一 个 member function (AKAM) ， 当 且 仅 当 它 
不 改变 object (对 象 ) 的 任何 data members (数据 成 员 ) (static (静态 的 ) RA) ， 也 就 
是 说 如 果 不 改变 object (对 象 ) 内 的 任何 bits (二 进 制 位 ) ， 则 这 个 member function (AKA 
函数 ) 就 是 const。bitwise constness (二 进 制 位 常量 性 ) 的 一 个 好 处 是 比较 容易 监测 违例 : 
编译 器 只 需要 寻找 对 data members (数据 成 员 ) 的 assignments (赋值 ) 。 实 际 上 ，bitwise 


constness (二 进 制 位 常量 性 ) 就 是 C++ 对 constness (常量 性 ) 的 定义 ， 一 个 const 
member function (ak A IER) 不 被 允许 改变 调用 它 的 object 〈 对 象 ) 的 任何 non-static data 
members ( 非 静 态 数据 成 员 ) 。 


不 幸 的 是 ， 很 多 效果 上 并 不 是 完全 const 的 member functions (AK AA) 通过 了 

bitwise (二 进 制 位 ) 的 检验 。 特 别 是 ， 一 个 经 常 改变 某 个 pointer (指针 ) 指向 的 内 容 的 
member function (AK A HO 效果 上 不 是 const 的 。 除 非 这 个 pointer (指针 ) 在 这 个 
object (对 象 ) FH, Bax SHAE bitwise (二 进 制 位 ) const 的 ， 编 译 器 也 不 会 提出 异 
议 。 例 如 ， 假 设 我 们 有 一 个 TextBlock-like class (类 似 TextBlock 的 类 ) ， 因 为 它 需 要 与 一 个 
不 知 string objects 〈 对 象 ) 为 何 物 的 C API 打交道 ， 所 以 它 需 要 将 它 的 数据 存储 为 char 而 
不 是 string。 


class CTextBlock { 
public: 


char& operator[](std::size_t position) const // inappropriate (but bitwise 


{ return pText[position]; } // const) declaration of 
// operator[] 
private: 
char *pText; 


J; 


尽管 operator[] 返回 a reference to the object's internal data (一 个 引 向 对 象 内 部 数据 的 引 
FA) ， 这 个 class (类 ) 还 是 (不适 当地) 将 它 声明 为 一 个 const member function (AK AH 
数 ) (Item 28 将 谈论 一 个 深入 的 主题 ) 。 先 将 它 放 到 一 边 ， 看 看 operator[] 的 实现 ， 它 并 没 
有 使 用 任何 手段 改变 pText。 结 果 ， 编 译 器 愉快 地 生成 了 operator[] 的 代码 ， 因 为 毕竟 对 所 有 
编译 器 而 言 ， 它 都 是 bitwise (二 进 制 位 ) const 的 ， 但 是 我 们 看 看 会 发 生 什么 : 


const CTextBlock cctb("Hello"); // declare constant object 


char *pc = &cctb[0]; // call the const operator[] to get a 
// pointer to cctb's data 


Holes Uae // cctb now has the value "Jello" 


这 里 确实 出 了 问题 ， 你 用 一 个 particular value (确定 值 ) 创建 一 个 constant object (常量 对 
象 ) ， 然 后 你 只 是 用 它 调用 了 const member functions ((KAWA) ， 但 是 你 还 是 改变 了 它 的 
值 ! 


这 就 引出 了 logical constness (逻辑 常量 性 ) 的 概念 。 这 一 理论 的 信徒 认为 : 一 个 const 
member function (AK A EEX) 可 能 会 改变 调用 它 的 object 〈 对 象 ) 中 的 一 些 bits (二 进 制 
位 ) ， 但 是 只 能 用 客户 无 法 察觉 的 方法 。 例 如 ， 你 的 CTextBlock class (类 ) 在 需要 的 时 候 可 
以 储存 文本 块 的 长 度 : 


class CTextBlock { 
public: 


std::size_t length() const; 


private: 
char *pText; 
std::size_t textLength; // last calculated length of textblock 
bool lengthIsValid; // whether length is currently valid 
}; 


std::size_t CTextBlock::length() const 


if (!lengthIsValid) { 
textLength = std::strlen(pText); // error! can't assign to textLength 
lengthIsValid = true; // and lengthIsValid in a const 

} // member function 


return textLength; 


} 


A 








length 的 实现 当然 不 是 bitwise (二 进 制 位 
会 被 改变 一 一 但 是 它 还 是 被 看 作对 const CTextBlock 对 象 有 效 。 但 编译 器 不 同意 ， 
持 bitwise constness (二进制 位 常量 性 ) ， 怎 么 办 呢 ? 


解决 方法 很 简单 : 利用 以 mutable 闻名 的 C++ 的 const-related (const 相关 ) 的 灵活 空间 。 
mutable 将 non-static data members 〈 非 静态 数据 成 员 ) 从 bitwise constness (二 进 制 位 常 
ett) 的 约束 中 解放 出 来 : 


class CTextBlock { 
public: 


std::size_t length() const; 


private: 
char *pText; 


mutable std::size_t textLength; // these data members may 
mutable bool lengthIsValid; // always be modified, even in 
}; // const member functions 


std::size_t CTextBlock::length() const 


if (!lengthIsValid) { 


textLength = std::strlen(pText); // now fine 
lengthIsValid = true; // also fine 
} 
return textLength; 


} 


避免 const 和 non-const member functions (成 员 画 数 ) 的 重复 


mutable 对 于 解决 bitwise-constness-is-not-what-l-had-in-mind (二 进 制 位 常量 性 不 太 合 我 的 
心意 ) 的 问题 是 一 个 不 错 的 解决 方案 ， 但 它 不 能 解决 全 部 的 const-related 相关 ) 难 
题 。 例 如 ， 假 设 TextBlock (包括 CTextBlock) 中 的 operator] 不 仅 要 返 适当 的 字符 的 


reference (引用 ) ， 它 还 要 进行 bounds checking (边界 检查 ) , logged access 
information (记录 访问 信息 ) ， 甚 至 data integrity validation (数据 完整 性 确认 ) ， 将 这 些 功 
能 都 加 入 到 const 和 non-const 的 operator[] BHAA (不 必 为 我 们 现在 有 着 非凡 长 度 的 
implicitly inline functions (4BAKWR) 而 烦恼 ， 参 见 Item 30) ， 使 它们 变 成 如 下 这 样 的 
庞然大物 : 


class TextBlock { 
public: 


const char& operator[](std::size_t position) const 


// do bounds checking 

// log access data 
nes // verify data integrity 
return text[position]; 


char& operator[](std::size_t position) 
// do bounds checking 
// log access data 
ae: // verify data integrity 
return text[position]; 


private: 
std::string text; 


}; 


哎呀 ! 你 是 说 code duplication (重复 代码 ) ?还 有 随 之 而 来 的 额外 的 编译 时 间 ， 维 护 成 本 以 
及 代码 膨胀 等 伟人 头痛 之 类 的 事情 吗 ? 当然 ， 也 可 以 将 bounds checking (边界 检查 ) 等 全 部 
代码 转移 到 一 个 单独 的 member function (AK AER) (自然 是 private (私有 ) 的 ) 中 ， 并 
让 两 个 版 本 的 operator] 来 调用 它 ， 但 是 ， 你 还 是 要 重复 写 出 调用 那个 落 数 和 return 语句 的 
代码 。 


你 真正 要 做 的 是 只 实现 一 次 operator[] 的 功能 ， 而 使 用 两 次 。 换 句 话说 ， 你 可 以 用 一 个 版 本 的 
operator] 去 调用 另 一 个 版 本 。 并 可 以 为 我 们 casting away (通过 强制 转型 脱 掉 ) 
constness (常量 性 ) 。 


作为 一 个 通用 规则 ，casting 〈 强 制 转 型 ) 是 一 个 非常 坏 的 主意 ， 我 会 投入 整个 一 个 Item 的 篇 
幅 来 告诉 你 不 要 使 用 它 (Item 27) ， 但 是 code duplication (重复 代码 ) 也 不 是 什么 好 事 。 在 
当前 情况 下 ，const 版 本 的 operator[] 所 做 的 事 也 正 是 non-const 版 本 所 做 的 ， 仅 有 的 不 同 是 
它 有 一 个 const-qualified return type (被 const 修饰 的 返回 类 型 ) 。 在 这 种 情况 下 ，casting 
away (通过 强制 转型 脱 掉 ) return value (返回 类 型 ) 的 const 是 安全 的 ， 因 为 ， 无 论 谁 调用 
non-const operator[]， 首 先 要 有 一 个 non-const object (对 象 ) 。 否 则 ， 它 不 能 调用 一 个 non- 
const 画 数 。 所 以 ， 即 使 需要 一 个 cast (强制 转型 ) ， 让 non-const operator[] 调用 const 版 
本 也 是 避免 重复 代码 的 安全 方法 。 代 码 如 下 ， 你 读 了 后 面 的 解释 后 对 它 的 理解 可 能 会 更 加 清 
晰 : 


class TextBlock { 
public: 


const char& operator[](std::size_t position) const // same as before 


return text[position]; 


char& operator[](std::size_t position) // now just calls const op[] 
return 
const_cast<char&>( // cast away const on 
// op[]'s return type; 
static_cast<const TextBlock&>(*this) // add const to *this's type; 
[position] // call const version of op[] 
); 
} 


正如 你 看 到 的 ， 代 码 中 有 两 处 casts (强制 转型 )， 而 不 是 一 处 。 我 们 让 non-const operator[] 
调用 const 版 本 ， 但 是 ， 如 果 在 non-const operator[] 的 内 部 ， 我 们 仅仅 是 调用 operator[]， 
那 我 们 将 递归 调用 我 们 自己 。 它 会 进行 一 百 万 次 甚至 更 多 。 为 了 避免 infinite recursion (ZR 
Ya) ， 我 们 必须 明确 指出 我 们 要 调用 const operator[]， 但 是 没有 直接 的 办 法 能 做 到 这 一 
点 ， 于 是 我 们 将 this 从 TextBlock& 的 自然 类 型 强制 转型 到 const TextB/ock&。 是 的 ， 我 们 使 
用 cast (强制 转型 ) 为 它 加 上 了 const! 所 以 我 们 有 两 次 casts (强制 转型 ) : 第 一 次 是 为 
this 加 上 const (以 便 在 我 们 调用 operator[] 时 调用 它 的 const 版 本 ) ， 第 二 次 是 从 const 
operator[] 的 return value (返回 值 ) 之 中 去 掉 const. 


加 上 const 的 cast 〈 强 制 转型 ) 仅仅 是 强制 施加 一 次 安全 的 转换 (从 一 个 non-const 

object (对 象 ) 到 一 个 const object (4R) ) ， 所 以 我 们 用 一 个 static_cast 来 做 。 去 掉 
const 只 能 经 由 const_cast 来 完成 ， 所 以 在 这 里 我 们 没有 别 的 选择 。 ERRE, RNA. 
一 个 C-style cast (C 风格 的 强制 转型 ) 也 能 工作 ， 但 是 ， 就 像 我 在 Item 27 中 解释 的 ， 这 样 
的 casts (强制 转型 ) 很 少 是 一 个 正确 的 选择 。 如 果 你 不 熟悉 static_cast 或 const_cast, Item 
27 中 包含 有 一 个 概述 。 ) 


在 完成 其 它 事 情 的 基础 上 ， 我 们 在 此 例 中 调用 了 一 个 operator (操作 符 ) ， 所 以 ， 语 法 看 上 
去 有 些 奇怪 。 导 致 其 不 会 赢得 选美 比 宾 ， 但 是 它 根 据 const 版 本 的 operator[] 实现 其 non- 
const 版 本 而 避免 code duplication (代码 重复 ) 的 方法 达到 了 预期 的 效果 。 使 用 竺 陋 的 语法 
达到 目标 是 否 值 得 最 好 由 你 自己 决定 ， 但 是 这 种 根据 const member function (A AMA) 实 
现 它 的 non-const 版 本 的 技术 却 非常 值得 掌握 。 


更 加 值得 掌握 的 是 做 这 件 事 的 反 向 方法 通过 用 const 版 本 调用 non-const 版 本 来 避免 重复 
一 一 是 你 不 能 做 的 。 记 住 ， 一 个 const member function (KR WA) 承诺 绝 不 会 改变 它 的 
object (对 象 ) 的 逻辑 状态 ， 但 是 一 个 non-const member function (AK A EAM) 不 会 做 这 样 





的 承诺 。 如 果 你 从 一 个 const member function (PX A R2) 调用 一 个 non-const member 
function (AX APR) ， 你 将 面临 你 承诺 不 会 变化 的 object (GR) 被 改变 的 风险 。 这 就 是 为 
什么 使 用 一 个 const member function (PX 7 KZO 调用 一 个 non-const member function (成 
AA) 是 错误 的 ，object (对 象 ) 可 能 会 被 改变 。 实 际 上 ， 那 样 的 代码 如 果 想 通过 编译 ， 你 
必须 用 一 个 const_cast 来 去 掉 this 的 const， 这 是 一 个 显而易见 的 麻烦 。 而 反 向 的 调用 一 一 
就 像 我 在 上 面 用 的 一 一 是 安全 的 : 一 个 non-const member function (PX AFR) 对 一 个 
object (对 象 ) 能 够 为 所 欲 为 ， 所 以 调用 一 个 const member function (AK ARR) 也 没有 任 
何 风险 。 这 就 是 为 什么 static_cast 在 这 种 情况 下 可 以 工作 在 this 上 的 原因 : 这 里 没有 const- 
related 危险 。 


就 像 在 本 Item 开始 我 所 说 的 ，const 是 一 件 美妙 的 东西 。 在 pointers (484+) 和 iterators G 
RÆ) 上 ， 在 pointers (指针 ) , iterators (迭代 器 ) 和 references (引用 ) 涉及 到 的 

object (对 象 ) 上 ， 在 function parameters (WWE) 和 return types (返回 值 ) 上 ， 在 
local variables (局 部 变量 ) 上 ， 在 member functions (AK AHR) 上 ，const 是 一 个 强 有 力 
的 盟友 。 只 要 可 能 就 用 它 ， 你 会 为 你 所 做 的 感到 高 兴 。 


Things to Remember 


。 将 某 些 东西 声明 为 const 有 助 于 编译 器 发 现 使 用 错误 。const 能 被 用 于 任何 scope ( 范 
A) 中 的 object (对 象 ) ， 用 于 function parameters (WARE) 和 return types (返回 
类 型 ) ， 用 于 整个 member functions (PX A WAL) 。 


。 编译 器 坚持 bitwise constness (二 进 制 位 常量 性 ) ， 但 是 你 应 该 用 conceptual 
constness (概念 上 的 常量 性 ) 来 编程 。 (此 处 原文 有 误 ，conceptual constness 为 作者 
在 本 书 第 二 版 中 对 logical constness 的 称呼 ， 正 文中 的 称呼 改 了 ， 此 你 却 没 有 改 。 其 实 
此 处 还 是 作者 新 加 的 部 分 ， 却 使 用 了 旧 的 术语 ， 怪 1 译 者 注 ) 





e 当 const 和 non-const member functions (AKAMA) 具有 本 质 上 相同 的 实现 的 时 候 ， 使 
用 non-const 版 本 调用 const 版 本 可 以 避免 code duplication (代码 重复 ) 。 


Item 4: 确保 objects (stk) 在 使 用 前 被 初始 化 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


C++ 看 上 去 在 对 象 的 值 的 初始 化 方面 变化 莫 测 。 例 如 ， 如 果 你 这 样 做 ， 


int x; 


在 某 些 情形 下 ，x 会 被 初始 化 (为 0) ， 但 是 在 其 它 情 形 下 ， 也 可 能 没有 。 如 果 你 这 样 做 ， 


class Point { 
int x, y; 


Point p; 


p 的 data members (数据 成 员 ) 有 时 会 被 初始 化 (为 0) ， 但 有 时 没有 。 如 果 你 从 一 个 不 存 
在 uninitialized objects (未 初始 化 对 象 ) 的 语言 来 到 C++， 请 注意 这 个 问题 ， 因 为 它 非 常 重 
要 。 


读 取 一 个 uninitialized values (未 初始 化 值 ) 会 引起 undefined behavior (未 定义 行为 ) 。 在 
一 些 平 台 上 ， 读 一 个 uninitialized value (未 初始 化 值 ) 会 引起 程序 中 止 ， 更 可 能 的 情况 是 得 
到 一 个 你 所 读 的 那个 位 置 上 的 semi-random bits ( 半 随 机 二 进 制 位 ) ， 最 终 导 致 不 可 预测 的 
程序 行为 和 恼人 的 调试 。 


现在 ， 有 一 些 描述 关于 什么 时 候 能 保证 Object initialization (对 象 初始 化 ) 会 发 生 什 么 时 候 不 
能 保证 的 规则 。 不 幸 的 是 ， 这 些 规 则 很 复 厅 一 一 我 觉得 它 复杂 得 无 法 记 住 。 通 常 ， 如 果 你 使 
用 C++ 的 C 部 分 (参见 ltem 1) ， 而 且 initialization (初始 化 ) 可 能 会 花费 一 些 运行 时 间 ， 

它 就 不 能 保证 发 生 。 如 果 你 使 用 C++ 的 non-C 部 分 ， 事 情 会 有 些 变 化 。 这 就 是 为 什么 一 个 

array (数组 ) (来 自 C++ 的 C 部 分 ) 不 能 确保 它 的 元 素 被 初始 化 ， 但 是 一 个 vector (KA 
C++ 的 STL 部 分 ) 就 能 够 确保 。 


处 理 这 种 事情 的 表面 不 确定 状态 的 最 好 方法 就 是 总 是 在 使 用 之 前 初始 化 你 的 对 象 。 对 于 built- 
in types (内 建 类 型 ) 的 non-member objects (〈 非 成 员 对 象 ) ， 需 要 你 手动 做 这 件 事 。 例 如 : 


int x = 0; // manual initialization of an int 


const char * text = "A C-style string"; // manual initialization of a 
// pointer (see also Item 3) 


double d; // “initialization" by reading from 


std::cin >> d; // an input stream 


除 此 之 外 的 几乎 全 部 情况 ，initialization (初始 化 ) 的 重任 就 落 到 了 constructors (构造 函数 ) 
的 身上 。 这 里 的 规则 很 简单 : 确保 all constructors (所 有 的 构造 画 数 ) 都 初始 化 了 
object 〈 对 象 ) 中 的 每 一 样 东 西 。 


这 个 规则 很 容易 遵守 ， 但 重要 的 是 不 要 把 assignment (赋值 ) 和 initialization (初始 化 ) fa 
混 。 考 虑 下 面 这 个 表现 一 个 通讯 录 条 目的 class (类 ) 的 constructor (构造 画 数 ) 


class PhoneNumber { ... }; 
class ABEntry { // ABEntry = "Address Book Entry" 
public: 


ABEntry(const std::string& name, const std::string& address, 
const std::list<PhoneNumber>& phones); 


private: 
std::string theName; 
std::string theAddress; 
std::list<PhoneNumber> thePhones; 
int num TimesConsulted; 

}; 


ABEntry::ABEntry(const std::string& name, const std::string& address, 
const std::list<PhoneNumber>& phones) 


theName = name; // these are all assignments, 
theAddress = address; // not initializations 
thePhones = phones; 


numTimesConsulted = 0; 


这 样 做 虽然 使 得 ABEntry objects (对 象 ) 具有 了 你 所 期 待 的 值 ， 但 还 不 是 最 好 的 做 法 。Cr++ 
的 规则 规定 一 个 object (对 象 ) 的 data members (数据 成 员 ) 在 进入 constructor (ER 
数 ) 的 函数 体 之 前 被 初始 化 。 在 ABEntry 的 constructor (构造 画 数 ) A, theName, 
theAddress 和 thePhones 不 是 being initialized (被 初始 化 ) ， 而 是 being assigned (被 赋 
值 ) 。initialization (初始 化 ) 发 生得 更 早 一 一 在 进入 ABEntry 的 constructor (ERN) 的 


画 数 体 之 前 ， 它 们 的 default constructors 〈 缺 省 的 构造 函数 ) 已 经 被 自动 调用 。 但 不 包括 
numTimesConsulted， 因 为 它 是 一 个 built-in type (内 建 类 型 ) 。 不 能 保证 它 在 被 赋值 之 前 被 
初始 化 。 


一 个 更 好 的 写 ABEntry constructor (4378292) 的 方法 是 用 member initialization list (成 员 
初始 化 列表 ) 来 代替 assignments (赋值 ) 


ABEntry::ABEntry(const std::string& name, const std::string& address, 
const std::list<PhoneNumber>& phones) 


: theName(name), 
theAddress(address), // these are now all initializations 
thePhones(phones), 
numTimesConsulted(0) 


{} // the ctor body is now empty 


这 个 constructor (ERAO 的 最 终结 果 和 前 面 那个 相同 ， 但 是 通常 它 有 更 高 的 效率 。 
assignment-based (基于 赋值 ) 的 版 本 会 首先 调用 default constructors ( 缺 省 构造 范 数 ) 初 
始 化 theName, theAddress 和 thePhones， 然 而 很 快 又 在 default-constructed ( 缺 省 构造 ) 
的 值 之 上 赋予 新 值 。 那 些 default constructions (ApEn) 所 做 的 工作 被 浪费 了 。 而 
member initialization list (成 员 初 始 化 列表 ) 的 方法 避免 了 这 个 问题 ， 因 为 initialization 

list (初始 化 列表 ) 中 的 arguments (参数 ) 就 可 以 作为 各 种 data members (数据 成 员 ) 的 
constructor (构造 函数 ) 所 使 用 的 arguments (参数 ) 。 在 这 种 情况 下 ，theName M name 
中 copy-constructed (拷贝 构造 ) ，theAddress M address 中 copy-constructed (拷贝 构 
造 ) , thePhones 从 phones 中 copy-constructed (拷贝 构造 ) 。 对 于 大 多 数 类 型 来 说 ， 只 调 
用 一 次 copy constructor (拷贝 构造 画 数 ) 的 效率 比 先 调 用 一 次 default constructor (A7 
SEX) 再 调用 一 次 copy assignment operator (拷贝 赋值 运算 符 ) 的 效率 要 高 (有 时 会 高 很 
多 ) 。 


对 于 numTimesConsulted 这 样 的 built-in type (内 建 类 型 ) 的 objects (对 象 ) ， 

initialization (初始 化 ) 和 assignment (m4) 没有 什么 不 同 ， 但 为 了 统一 性 ， 最 好 是 经 由 
member initialization (成 员 初 始 化 ) Æ initialize (初始 化 ) 每 一 件 东西 。 类 似 地 ， 当 你 只 想 
default-construct ( 缺 省 构造 ) 一 个 data member (数据 成 员 ) 时 也 可 以 使 用 member 
initialization list (成 员 初 始 化 列表 ) ， 只 是 不 必 指 定 initialization argument (初始 化 参数 ) 而 
已 。 例 如 ， 如 果 ABEntry 有 一 个 不 取得 parameters (参数 ) 的 constructor (构造 函数 ) ， 它 
可 以 像 这 样 实现 : 


ABEntry: :ABEntry() 


:theName(), // call theName's default ctor; 
theAddress(), // do the same for theAddress; 
thePhones(), // and for thePhones; 
numTimesConsulted(0) // but explicitly initialize 


{} // numTimesConsulted to zero 


因为 对 于 那些 在 member initialization list (成 员 初 始 化 列表 ) 中 的 ， 没 有 initializers (初始 化 
器 ) 的 ，user-defined types (用 户 自 定义 类 型 ) 的 data members (数据 成 员 ) ， 编 译 器 会 自 
动 调用 其 default constructors (人 缺 省 构造 画 数 ) ， 所 以 一 些 程 序 员 会 认为 上 面 的 方法 有 些 过 
分 。 这 也 不 难 理解 ， 但 是 一 个 方针 是 : 在 initialization list (初始 化 列表 ) 中 总 是 列 出 每 一 个 
data member (数据 成 员 ) ， 这 就 可 以 避免 一 旦 发 生 玻 漏 就 必须 回忆 起 可 能 是 哪 一 个 data 
members (数据 成 员 ) 没有 被 初始 化 。 例 如 ， 因 为 numTimesConsulted 是 一 个 built-in 

type (内 建 类 型 ) ， 如 果 将 它 从 member initialization list (成 员 初 始 化 列表 ) PRR, WA 
undefined behavior (未 定义 行为 ) 打开 了 方便 之 门 。 


有 时 ， 即 使 是 built-in types (内 建 类 型 ) initialization list (初始 化 列表 ) 也 必须 使 用 。 比 
如 ，const 或 references (引用 ) data members (数据 成 员 ) 是 必须 be initialized (被 初始 
化 ) 的 ， 它 们 不 能 be assigned (被 赋值 ) (参见 ltem 5) 。 为 了 避免 记忆 什么 时 候 data 
members (数据 成 员 ) 必须 在 member initialization list (成 员 初 始 化 列表 ) 中 初始 化 ， 而 什 
么 时 候 又 是 可 选 的 ， 最 简单 的 方法 就 是 总 是 使 用 initialization list (初始 化 列表 ) 。 它 有 时 是 
必须 的 ， 而 且 它 通常 都 比 assignments (赋值 ) 更 有 效率 。 


很 多 classes (#) 有 多 个 constructors (nE) ， 而 每 一 个 constructor GERZ) 都 
有 自己 的 member initialization list (成 员 初 始 化 列表 ) 。 如 果 有 很 多 data members (数据 成 
A) 和 /或 base classes ( 基 类 ) ， 成 倍增 加 的 initialization lists (初始 化 列表 ) 的 存在 引起 兮 
人 郁闷 的 重复 (EIRP) 和 厌烦 (在 程序 员 中 ) 。 在 这 种 情况 下 ， 不 能 不 讲 道理 地 从 列表 
中 删除 那些 assignment (赋值 ) 和 true initialization (真正 的 初始 化 ) 一 样 工 作 的 data 
members (数据 成 员 ) RA, m2 assignments (赋值 ) 移 到 一 个 单独 的 (当然 是 
private (私有 ) AY) Bae, LAAT constructors (ERA) 调用 。 这 个 方法 对 于 那些 
true initial values (真正 的 初始 值 ) 是 从 文件 中 读 入 或 从 数据 库 中 检索 出 来 的 data 

members (数据 成 员 ) 特别 有 帮助 。 然 而 ， 通 常情 况 下 ，true member initialization (真正 的 
成 员 初 始 化 ) (经 由 一 个 initialization list (初始 化 列表 ) ) 比 经 由 assignment (赋值 ) 来 进 
行 的 pseudo-initialization ( 假 初始 化 ) 更 可 取 。 


C++ 并 非 变 幻 莫 测 的 方面 是 一 个 object (GR) 的 数据 被 初始 化 的 顺序 。 这 个 顺序 总 是 相同 
的 : base classes ( 基 类 ) 在 derived classes (派生 类 ) 之 前 被 初始 化 (BR ltem 12) ， 在 
一 个 class (类 ) 内 部 ，data members (数据 成 员 ) 按照 它们 被 声明 的 顺序 被 初始 化 。 例 
如 ， 在 ABEntry 中 ，theName 总 是 首先 被 初始 化 ，theAddress 是 第 二 个 ，thePhones 第 
=, numTimesConsulted 最 后 。 即 使 它们 在 member initialization list (成 员 初 始 化 列表 ) 中 
以 一 种 不 同 的 顺序 排列 〈 这 不 幸 合 法 ) ， 这 依然 是 成 立 的 。 为 了 避免 读者 混淆 ， 以 及 一 些 模 
糊 不 清 的 行为 引起 错误 的 可 能 性 ，initialization list (初始 化 列表 ) 中 的 members (成 员 ) 的 
排列 顺序 应 该 总 是 与 它们 在 class (类 ) 中 被 声明 的 顺序 保持 一 致 。 


一 旦 处 理 了 built-in types (内 建 类 型 ) 的 non-member objects ( 非 成 员 对 象 ) 的 显 式 初始 
化 ， 而 且 确 保 你 的 constructors (构造 画 数 ) 使 用 member initialization list (成 员 初 始 化 列 
KR) 初始 化 了 它 的 base classes ( 基 类 ) 和 data members (数据 成 员 ) ， 那 就 只 剩 下 一 件 事 
情 需 要 费心 了 。 那 就 是 一 一 深呼吸 先 一 一 定义 在 不 同 translation units (转换 单元 ) 中 的 non- 
local static objects 〈 非 局 部 静态 对 象 ) 的 initialization (初始 化 ) 的 顺序 。 





让 我 们 一 片 一 片 地 把 这 个 词组 拆 开 。 


一 个 static object (HAR) 的 生存 期 是 从 它 创 建 开始 直到 程序 结束 。stack and heap- 
based objects (基于 堆栈 的 对 象 ) 就 被 排除 在 外 了 。 包 括 global objects 〈 全 局 对 象 ) ， 
objects defined at namespace scope (定义 在 命名 空间 范围 内 的 对 象 ) ，objects declared 
static inside classes (在 类 内 部 声明 为 静态 的 对 象 ) ，objects declared static inside 
functions (JER A ABB AB A af ABI xt) M objects declared static at file scope (在 文件 范 
围 内 被 声明 为 静态 的 对 象 ) . static objects inside functions (ERARA SR) 以 
local static objects 〈 局 部 静态 对 象 ) (因为 它 局 部 于 函数 ) 为 人 所 知 ， 其 它 各 种 static 
objects (静态 对 象 ) 以 non-local static objects ( 非 局 部 静态 对 象 ) 为 人 所 知 。 程 序 结束 时 
static objects (MAUR) 会 自动 销毁 ， 也 就 是 当 main 停止 执行 时 会 自动 调用 它们 的 
destructors ( 析 构 图 数 ) 。 


一 个 translation unit (转换 单元 ) 是 可 以 形成 一 个 单独 的 object file (目标 文件 ) 的 source 
code ( 源 代码 ) 。 基 本 上 是 一 个 单独 的 source file CRX) ， 再 加 上 它 全 部 的 #include X 
件 。 


我 们 关心 的 问题 是 这 样 的 : 包括 至 少 两 个 分 别 编 译 的 source filles RX) ， 每 一 个 中 都 至 
少 包含 一 个 non-local static object ( 非 局 部 静态 对 象 ) (也 就 是 说 ，global (全 局 ) 的 ，at 
namespace scope (命名 空间 范围 ) 的 ，static in a class (类 内 ) 的 或 at file scope (文件 范 
围 ) BY object (对 象 ) ) 。 实 际 的 问题 是 这 样 的 : 如 果 其 中 一 个 translation unit (转换 单元 ) 
内 的 一 个 non-local static object ( 非 局 部 静态 对 象 ) 的 initialization (初始 化 ) 用 到 另 一 个 
translation unit (转换 单元 ) 内 的 non-local static object ( 非 局 部 静态 对 象 ) ， 它 所 用 到 的 
object (对 象 ) 可 能 没有 被 初始 化 ， 因 为 the relative order of initialization of non-local static 
objects defined in different translation units is undefined (定义 在 不 同 转换 单元 内 的 非 局 部 静 
态 对 象 的 初始 化 的 相对 顺序 是 没有 定义 的 ) 。 


一 个 例子 可 以 帮助 我 们 。 假 设 你 有 一 个 FileSystem class (类 ) ， 可 以 使 Internet 上 的 文件 看 
起 来 就 像 在 本 地 。 因 为 你 的 class 〈 类 ) 使 得 世界 看 起 来 好 像 只 有 一 个 单独 的 file system (X 
件 系统 ) ， 你 可 以 在 global (全 局 ) 或 namespace (命名 空间 ) 范围 内 创建 一 个 专门 的 
object (对 象 ) 来 代表 这 个 单独 的 file system (文件 系统 ) 


class FileSystem { // from your library 
public: 
std::size_t numDisks() const; // one of many member functions 
e 
extern FileSystem tfs; // object for clients to use; 
// "tfs" = "the file system" 


一 个 FileSystem object (4R) 绝对 是 举足轻重 的 ， 所 以 在 theFileSystem object (对 象 ) 被 
创建 之 前 就 使 用 将 会 损失 惨重 。 


现在 假设 一 些 客户 为 一 个 file system (文件 系统 ) 中 的 目录 创建 了 一 个 class (类 ) ， 他 们 的 
class (#) 使 用 了 theFileSystem object (对 象 ) 


class Directory { // created by library client 
public: 


Directory( params ); 


ree 
Directory: :Directory( params ) 
{ 

std::size_t disks = tfs.numDisks(); // use the tfs object 
: oy: 


更 进一步 ， 假 设 这 个 客户 决定 为 临时 文件 创建 一 个 单独 的 Directory object (xt &) 


Directory tempDir( params ); // directory for temporary files 


现在 initialization order (初始 化 顺序 ) 的 重要 性 变 得 明显 了 : 除非 tfs 在 tempDir 之 前 初始 
化 ， 否 则 ，tempDir 的 constructor (HERO 就 会 在 tis 被 初始 化 之 前 试图 使 用 它 。 但 是 ， 
tfs 和 tempDir 是 被 不 同 的 人 于 不 同 的 时 间 在 不 同 的 source files ( 源 文 件 ) 中 创建 的 一 一 它们 
是 定义 在 不 同 translation units (转换 单元 ) 中 的 non-local static objects ( 非 局 部 静态 对 

R) 。 你 怎么 能 确保 t 一 定 会 在 tempDir 之 前 被 初始 化 呢 ? 


你 不 能 。 重 申 一 通 ，the relative order of initialization of non-local static objects defined in 
different translation units is undefined (定义 在 不 同 转 换 单元 内 的 非 局 部 静态 对 象 的 初始 化 的 
相对 顺序 是 没有 定义 的 ) 。 这 是 有 原因 的 。 决 定 non-local static objects ( 非 局 部 静态 对 象 ) 
的 “恰当 的 "初始 化 顺序 是 困难 的 ， 非 常 困 难 ， 以 至 于 无 法 完成 。 在 最 常见 的 形式 下 一 一 多 个 
translation units (转换 单元 ) 和 non-local static objects ( 非 局 部 静态 对 象 ) 通过 implicit 
template instantiations ( 隐 式 模板 实例 化 ) 产生 (这 本 身 可 能 也 是 经 由 implicit template 
instantiations ( 隐 式 模板 实例 化 ) 引起 的 ) 不 仅 不 可 能 确定 一 个 正确 的 initialization ( 初 
始 化 ) 顺序 ， 甚 至 不 值得 去 寻找 可 能 确定 正确 顺序 的 特殊 情况 。 





幸运 的 是 ， 一 个 小 小 的 设计 改变 从 根本 上 解决 了 这 个 问题 。 全 部 要 做 的 就 是 将 每 一 个 non- 
local static object ( 非 局 部 静态 对 象 ) 移 到 它 自己 的 函数 中 ， 在 那里 它 被 声明 为 static ( 静 
态 ) 。 这 些 函 数 返回 它 所 包含 的 objects (对 象 ) 的 引用 。 客 户 可 以 调用 这 些 函 数 来 代替 直接 
涉及 那些 objects (对 象 ;。 换 一 种 说 法 ， 就 是 用 local static objects (局 部 静态 对 象 ) 取代 
non-local static objects ( 非 局 部 静态 对 象 ) 。 (aficionados of design patterns (设计 模式 迷 
们 ) 会 认 出 这 是 Singleton 模式 的 通用 实现 ) o 


这 个 方法 建立 在 C++ 保证 local static objects (局 部 静态 对 象 ) 的 初始 化 发 生 在 因为 调用 那个 
责 数 而 第 一 次 遇 到 那个 object (对 象 ) 的 definition (定义 ) 时 候 。 所 以 ， 如 果 你 用 调用 返回 
references to local static objects 〈 局 部 静态 对 象 的 引用 ) 的 函数 的 方法 取代 直接 访问 non- 


local static objects 〈 非 局 部 静态 对 象 ) 的 方法 ， 你 将 确保 你 取 回 的 references (引用 ) 51 
initialized objects (已 初始 化 的 对 象 ) 。 作 为 一 份额 外 收获 ， 如 果 你 从 不 调用 这 样 一 个 仿效 
non-local static object ( 非 局 部 静态 对 象 ) 的 函数 ， 你 就 不 会 付出 创建 和 销毁 这 个 object (对 
R) 的 代价 ， 而 一 个 true non-local static objects (真正 的 非 局 部 静态 对 象 ) 则 不 会 有 这 样 的 
效果 。 


以 下 就 是 这 项 技术 在 tfs 和 tempDir 上 的 应 用 : 


class FileSystem { ... }; // as before 
FileSystem& tfs() // this replaces the tfs object; it could be 
// static in the FileSystem class 
static FileSystem fs; // define and initialize a local static object 
return fs; // return a reference to it 
class Directory { ... }; // as before 
Directory: :Directory( params ) // as before, except references to tfs are 


// now to tfs() 


std::size_t disks = tfs().numDisks(); 


} 
Directory& tempDir() // this replaces the tempDir object; it 
// could be static in the Directory class 
static Directory td; // define/initialize local static object 
return td; // return reference to it 


这 个 改良 系统 的 客户 依然 可 以 按照 他 们 已 经 习惯 的 方法 编程 ， 只 是 他 们 现在 应 该 用 tfs() 和 
tempDir() 来 代替 tfs 和 tempDir。 也 就 是 说 ， 他 们 应 该 使 用 返回 references to objects 〈 对 象 
引用 ) 的 函数 来 代替 使 用 objects themselves (对 象 自身 ) 。 


按照 以 下 步 又 来 写 reference-returning functions (返回 引用 的 函数 ) 总 是 很 简单 : 在 第 1 行 

定义 并 初始 化 一 个 local static object 〈 局 部 静态 对 象 ) ， 在 第 2 行 返回 它 。 这 样 的 简单 使 它 

们 成 为 inlining (内 联 化 ) 的 完美 的 候选 者 ， 特 别 是 在 它们 被 频繁 调用 的 时 候 (参见 Item 

30) 。 在 另 一 方面 ， 这 些 辑 数 包含 static object (静态 对 象 ) 的 事实 使 它们 在 multithreaded 

systems (多 线程 系统 ) 中 会 出 现 问 题 。 更 进一步 ， 任 何 种 类 的 non-const static object (非常 
量 静 态 对 象 ) — local (局 部 ) 的 或 non-local ( 非 局 部 ) 的 i 多 线 

程 ) 存在 的 场合 都 会 发 生 麻 烦 。 解 决 这 个 麻烦 的 方法 之 一 是 在 程序 的 single-threaded (单线 

E) 的 启动 部 分 手动 调用 所 有 的 reference-returning functions (返回 引用 的 函数 ) 。 以 此 来 

避免 initialization-related (与 初始 化 相关 ) 的 混乱 环境 。 





当然 ， 用 reference-returning functions OROBI ARRO 来 防止 initialization order 
problems (初始 化 顺序 问题 ) 的 想法 首先 依赖 于 你 的 objects tR) 有 一 个 合理 的 
initialization order (初始 化 顺序 ) 。 如 果 你 有 一 个 系统 ， 其 中 object A X os object B 之 前 
初始 化 ， 但 是 A 的 初始 化 又 依赖 于 B 已 经 被 初始 化 ， 你 将 遇 到 问题 ， 坦 白地 讲 ， 你 遇 到 大 麻 
类 了。 然而， 如 果 你 避 开 了 这 种 病态 的 境遇 ， 这 里 描述 的 方法 会 很 好 地 为 你 服务 ， 至 少 在 
single-threaded applications (单线 程 应 用 ) 中 是 这 样 。 


避免 在 初始 化 之 前 使 用 objects (st) ， 你 只 需要 做 三 件 事 。 首 先 ， 手 动 初 始 化 built-in 
types (内 建 类 型 ) 的 non-member objects ( 非 成 员 对 象 ) 。 第 二 ， 使 用 member 
initialization lists (成 员 初始 化 列表 ) 初始 化 一 个 object (tk) 的 所 有 部 分 。 最 后 ， 在 设计 
中 绕 过 搞 乱 定义 在 分 离 的 translation units (转换 单元 ) 中 的 non-local static objects ( 非 局 部 
静态 对 象 ) initialization order (初始 化 顺序 ) 的 不 确定 性 。 


Things to Remember 


© 手动 初始 化 built-in type (内 建 类 型 ) 的 objects (tk) ， 因 为 C++ 只 在 某 些 时 候 才 会 
自己 初始 化 它们 。 


。 在 constructor (构造 画 数 ) 中 ， 用 member initialization list (成 员 初 始 化 列表 ) KRW 
数 体 中 的 assignment (赋值 ) initialization list (初始 化 列表 ) 中 data members (数据 
成 员 ) 的 排列 顺序 要 与 它们 在 class (类 ) 中 被 声明 的 顺序 相同 。 


e 通过 用 local static objects (局 部 静态 对 象 ) 代替 non-local static objects ( 非 局 部 静态 对 
R) 来 避免 跨 translation units (转换 单元 ) 的 initialization order problems (初始 化 顺序 
问题 ) 。 


Item 5: 了 解 C++ 为 你 偷偷 地 加 上 和 调用 了 什么 落 
作者 : Scott Meyers 

译 者 : fatalerror99 (iTePub's Nirvana) 

发 布 : http://blog.csdn.net/fatalerror99/ 


一 个 empty class ( 空 类 ) 什么 时 候 将 不 再 是 empty class ( 空 类 ) ?答案 是 当 C++ 搞定 了 
它 。 如 果 你 自己 不 声明 一 个 copy constructor (#4 1 Mie) ， 一 个 copy assignment 
operator (拷贝 赋值 运算 符 ) 和 一 个 destructor (TARZ) ， 编 译 器 就 会 为 这 些 东 西 声 明 一 
个 它 自己 的 版 本 。 此 外 ， 如 果 你 自己 根本 没有 声明 constructor (AER) ， 编 译 器 就 会 为 
你 声明 一 个 default constructor 〈 缺 省 构造 画 数 ) 。 所 有 这 些 函 数 都 被 声明 为 public 和 
inline (参见 Item 30) 。 作 为 结果 ， 如 果 你 写 


class Empty{}; 


在 本 质 上 和 你 这 样 写 是 一 样 的 : 


class Empty { 


public: 
Empty() { ... } // default constructor 
Empty(const Empty& rhs) { ... } // copy constructor 
~Empty() { ... } // destructor — see below 
// for whether it's virtual 
Empty& operator=(const Empty& rhs) { ... } // copy assignment operator 
J; 


这 些 事 数 只 有 在 它们 被 需要 的 时 候 才 会 生成 ， 但 是 并 不 需要 做 太 多 的 事情 ， 就 会 用 到 它们 。 
下 面 的 代码 会 促使 每 一 个 画 数 生成 : 


Empty e1; // default constructor; 
// destructor 
Empty e2(e1); // copy constructor 
e2 = el; // copy assignment operator 


Rik Riss AIRE 7 XH, PAC HMA ANE ? default constructor ( 缺 省 构造 函数 ) 
和 destructor (4T#4ENaX) 主要 是 给 编译 器 一 个 地 方 放置 "behind the scenes" code (“幕后 ” 代 
码 ) 的 ， 诸 如 base classes ( 基 类 ) 和 non-static data members ( 非 静 态 数 据 成 员 ) 的 


constructors (74i6E2X) 和 destructor (TAKO 的 调用 。 注 意 ， 生 成 的 destructor 〈 析 构 
函数 ) 是 non-virtual ( 非 虚拟 ) 的 (参见 ltem 7) ， 除 非 它 所 在 的 class (类 ) 是 从 一 个 
base class ( 基 类 ) 继承 而 来 ， 而 base class ( 基 类 ) 自己 声明 了 一 个 virtual destructor (i 
DT MB) (这 种 情况 下 ， 画 数 的 virtualness (虚拟 性 ) 来 自 base class ( 基 类 ) ) 。 


对 于 copy constructor (拷贝 构造 男 数 ) 和 copy assignment operator (拷贝 赋值 运算 符 ) , 
compiler-generated versions (编译 器 生成 版 本 ) 只 是 简单 地 从 source object 〈 源 对 象 ) 拷贝 
每 一 个 non-static data member ( 非 静 态 数据 成 员 ) 到 target object (目标 对 象 ) 。 例 如 ， 考 
虑 一 个 NamedObject template (模板 ) ， 它 允许 你 将 名 字 和 类 型 为 下 的 objects (对 象 ) 联 
系 起 来 的 : 


template<typename T> 

class NamedObject { 

public: 
NamedObject(const char *name, const T& value); 
NamedObject(const std::string& name, const T& value); 


private: 

std::string nameValue; 
T objectValue; 

J; 


因为 NamedObject 中 声明 了 一 个 constructors (构造 范 数 ) ， 编 译 器 就 不 会 再 生成 一 个 
default constructor (WEERA) 。 这 一 点 很 重要 ， 它 意味 着 如 果 你 小 心地 设计 一 个 
class (#) ， 使 它 需要 constructor arguments (构造 函数 参数 ) ， 你 就 不 必 顾 虑 编译 器 会 不 
顾 你 的 决定 ， 轻 率 地 增加 一 个 不 需要 参数 的 constructors (ERR) 。 


NamedObject 既 没 有 声明 copy constructor (拷贝 构造 画 数 ) 也 没有 声明 copy assignment 
operator (拷贝 赋值 运算 符 ) ， 所 以 编译 器 将 生成 这 些 函 数 (如 果 需 要 它们 的 话 ) 。 看 ， 这 就 
是 copy constructor (#8 MiG ENR) 的 用 法 : 


NamedObject<int> noi("Smallest Prime Number", 2); 


NamedObject<int> no2(no1); // calls copy constructor 


编译 器 生成 的 copy constructor (H n #438) 一 定 会 用 not.nameValue 和 
no1.objectValue 分 别 初 始 化 no2.nameValue 和 no2.objectValue。nameValue 的 类 型 是 
string， 标 准 string 类 型 有 一 个 copy constructor (8M iS) ， 所 以 将 通过 以 
no1.nameValue 作为 参数 调用 string 的 copy constructor (4 1 iS) 初始 化 
no2.nameValue. m 4—H, NamedObject<int>::objectValue 的 类 型 是 int (因为 在 这 个 
template instantiation (模板 实例 化 ) Tint) , m int 是 built-in type (内 建 类 型 ) ， 所 以 
将 通过 拷贝 no1.objectValue 的 每 一 个 二 进 制 位 初始 化 no2.objectValue. 


编译 器 为 NamedObject<int> 生成 的 copy assignment operator (拷贝 赋值 运算 符 ) 本 质 上 也 
会 有 同样 的 行为 ， 但 是 ， 通 常情 况 下 ， 只 有 在 结果 代码 合法 而 且 有 一 个 合理 的 可 理解 的 巧合 

时 ，compiler-generated (编译 器 生成 ) 的 copy assignment operator ( 撕 贝 赋值 运算 符 ) F 
会 有 我 所 描述 的 行为 方式 。 如 果 这 两 项 检测 中 的 任 一 项 失败 了 ， 编 译 器 将 拒绝 为 你 的 

class (类 ) 生成 一 个 operator=。 


例如 ， 假 设 NamedObject 如 下 定义 ，nameValue 是 一 个 reference to a string ( 引 向 一 个 字 
符 串 的 引用 ) ， 而 objectValue 是 一 个 constT : 


template<class T> 

class NamedObject { 

public: 
// this ctor no longer takes a const name, because nameValue 
// is now a reference-to-non-const string. The char* constructor 
// is gone, because we must have a string to refer to. 
NamedObject(std::string& name, const T& value); 


// as above, assume no 
// operator= is declared 


private: 
std::string& nameValue; // this is now a reference 
const T objectValue; // this is now const 

}; 


现在 ， 考 虑 这 里 会 发 生 什么 : 


std::string newDog("Persephone"); 
std::string oldDog("Satch"); 


NamedObject<int> p(newDog, 2); // when I originally wrote this, our 
// dog Persephone was about to 
// have her second birthday 
NamedObject<int> s(oldDog, 36); // the family dog Satch (from my 
// childhood) would be 36 if she 
// were still alive 


p=s; // what should happen to 
// the data members in p? 


assignment (赋值 ) 之 前 ，p.nameValue 和 s.nameValue 都 引 向 string objects (对 象 ) , & 
然 并 非 同 一 个 。 那 个 assignment (赋值 ) 对 p.nameValue 产生 了 什么 影响 呢 ? 

assignment (赋值 ) 之 后 ，p.nameValue 所 引 向 的 string 是 否 就 是 s.nameValue 所 引 向 的 那 
一 个 呢 ， 也 就 是 说 ，reference (引用 ) KARAXT ?如 果 是 这 样 ， 就 违反 了 常规 ， 因 为 
C++ 并 没有 提供 使 一 个 reference (引用 ) 引 向 另 一 个 objects (tk) 的 方法 。 换 一 种 思 
路 ， 是 不 是 p.nameValue 所 引 向 的 那个 string objects (对 象 ) 被 改变 了 ， 从 而 影响 了 其 他 
objects (xt) 一 pointers (指针 ) 或 references (引用 ) 持续 指向 的 那个 string， 也 就 
是 ， 赋 值 中 并 没有 直接 涉及 到 的 对 象 ? 这 是 compiler-generated (编译 器 生成 ) 的 copy 
assignment operator (拷贝 赋值 运算 符 ) 应 该 做 的 事情 吗 ? 


面 对 这 个 难题 ，C++ 拒绝 编译 代码 。 如 果 你 希望 一 个 包含 reference member (引用 成 员 ) 的 
class (类 ) 支持 assignment (赋值 ) ， 你 必须 自己 定义 copy assignment operator (拷贝 赋 
值 运算 符 ) 。 对 于 含有 const members (const RA) 的 classes (类 ) ， 编 译 器 会 有 类 似 的 
行为 (就 像 上 面 那个 改变 后 的 class (类 ) 中 的 objectValue) 。 改 变 const members (const 
RA) 是 不 合法 的 ， 所 以 编译 器 隐 式 生成 的 assignment function (RARA) 无 法 确定 该 如 
何 对 待 它 们 。 最 后 ， 如 果 base classes ( 基 类 ) 将 copy assignment operator (拷贝 赋值 运算 
符 ) 声明 为 private， 编 译 器 拒绝 为 从 它 继承 的 derived classes (派生 类 ) 生成 implicit copy 
assignment operators ( 隐 式 拷贝 赋值 运算 符 ) 。 毕竟 ， 编 译 器 为 派生 类 生成 的 copy 
assignment operator (拷贝 赋值 运算 符 ) 也 要 处 理 其 base class parts ( 基 类 构件 ) (参见 
ltem 12) ， 但 如 果 这 样 做 ， 它 们 当然 无 法 调用 那些 derived classes (派生 类 ) 无 权 调 用 的 
member functions (AK A EBX) 。 


Things to Remember 


。 编译 器 可 以 隐 式 生成 一 个 class (#) 的 default constructor (dR WISER) , copy 
constructor (拷贝 构造 范 数 ) ，copy assignment operator (拷贝 赋值 运算 符 ) 和 
destructor ( 析 构 范 数 ) 。 


Item 6: 如 果 你 不 想 使 用 compiler-generated 
functions 《编译 堪 生 成 函 效 ) ， 残 明确 拒绝 


作者 : Scott Meyers 

译 者 : fatalerror99 (iTePub's Nirvana) 

发 布 : http://blog.csdn.net/fatalerror99/ 

房地产 代理 商 出 售 房屋 ， 服 务 于 这 样 的 代理 商 的 软件 系统 自然 要 有 一 个 class (类 ) 来 表示 被 
出 售 的 房屋 : 


class HomeForSale { ... }; 


每 一 个 房地产 代理 商都 会 很 快 指出 ， 每 一 件 房产 都 是 独特 的 一 一 没有 两 件 是 完全 一 样 的 。 在 

这 种 情况 下 ， 为 HomeForSale object (对 象 ) 做 一 个 copy Gn) 的 想法 就 伟人 不 解 了 。 你 
怎么 能 拷贝 一 个 独一无二 的 东西 呢 ?3 因此 最 好 让 类 似 这 种 企图 拷贝 HomeForSale object (对 
象 ) 的 行为 不 能 通过 编译 : 





HomeForSale h1; 
HomeForSale h2; 


HomeForSale h3(h1); // attempt to copy hi — should 
// not compile! 


h1 = h2; // attempt to copy h2 — should 
// not compile! 


唉 ， 防 止 这 种 编译 的 方法 并 非 那 么 简单 易 懂 。 通 常 ， 如 果 你 不 希望 一 个 class (类 ) 支持 某 种 
功能 ， 你 可 以 简单 地 不 声明 赋予 它 这 种 功能 的 函数 。 这 个 策略 对 于 copy constructor (拷贝 构 
iG EX 2X) 和 copy assignment operator (拷贝 赋值 运算 符 ) 不 起 作用 ， 因 为 ， 就 象 ltem 5 中 
指出 的 ， 如 果 你 不 声明 它们 ， 而 有 人 又 想 调用 它们 ， 编 译 器 就 会 替 你 声明 它们 。 


这 就 限制 了 你 。 如 果 你 不 声明 copy constructor (拷贝 构造 画 数 ) 或 copy assignment 
operator (拷贝 赋值 运算 符 ) ， 编 译 器 也 可 以 替 你 生成 它们 。 你 的 class (类 ) 还 是 会 支持 
copying (拷贝 ) 。 另 一 方面 ， 如 果 你 声明 了 这 些 函 数 ， 你 的 class 〈 类 ) 依然 会 支持 
copying (A) 。 而 我 们 此 时 的 目的 却 是 prevent copying (En) ! 


解决 这 个 问题 的 关键 是 所 有 的 编译 器 生成 的 函数 都 是 publice (AA) 的 。 为 了 防止 生成 这 些 函 

数 ， 你 必须 自己 声明 它们 ， 但 是 你 没有 理由 把 它们 声明 为 publice (AA) 的 。 相 反 ， 应 该 将 

copy constructor (拷贝 构造 男 数 ) 和 copy assignment operator (拷贝 赋值 运算 符 ) 声明 为 

private (私有 ) 的 。 通 过 显 式 声明 一 个 member function (X ABA) ， 可 以 防止 编译 器 生成 
它 自己 的 版 本 ， 而 且 将 这 个 函数 声明 为 private (私有 ) 的 ， 可 以 防止 别人 调用 它 。 


通常 ， 这 个 方案 并 不 十 分 保险 ， 因 为 member (成 员 ) 和 friend functions ( 友 元 函数 ) 还 

能 够 调用 你 的 private 函数 。 换 句 话 说 ， 除 非 你 十 分 聪明 地 不 define (定义 ) 它们 。 va ; “a 
有 人 不 小 心地 调用 了 它们 ， 在 link-time (连接 时 ) 会 出 现 错 误 。 这 个 窍门 一 一 声明 member 
functions (KARR) 为 private 却 故意 不 去 实现 它 一 确实 很 好 ， 在 C++ 的 iostreams 库 
里 ， 就 有 几 个 类 用 此 方法 prevent copying (防止 拷贝 ) 。 上 比如 ， 看 一 下 你 用 的 标准 库 的 实现 
中 ios_base, basic_ios 和 sentry 的 definitions (定义 ) ， 你 就 会 看 到 copy constructor (4# 
贝 构 造 范 数 ) 和 copy assignment operator (拷贝 赋值 运算 符 ) 被 声明 为 private 而 且 没有 被 
定义 的 情况 。 
将 这 个 窍门 用 到 HomeForSale 上 ， 很 简单 : 


class HomeForSale { 
public: 
private: 


HomeForSale(const HomeForSaleé&); // declarations only 
HomeForSale& operator=(const HomeForSale&) ; 


}; 


你 会 注意 到 ， 我 省 略 了 functions' parameters (HREM) 的 名 字 。 这 不 是 必须 的 ， 只 是 一 个 
普通 的 惯例 。 毕 竟 ， 画 数 不 会 被 实现 ， 更 少 会 被 用 到 ， 有 什么 必要 指定 参数 名 呢 ? 


对 于 上 面 的 class definition 〈 类 定义 ) ， 编 译 器 将 阻止 客户 拷贝 HomeForSale objects (对 
R) 的 企图 ， 如 果 你 不 小 心 在 member (成 员 ) 3 friend function 〈 友 元 函数 ) 中 这 样 做 了 ， 
连接 程序 会 提出 抗议 。 


将 link-time error (连接 时 错误 ) 提前 到 编译 时 间 也 是 可 行 的 〈 早 发 现 错 误 毕 竟 比 晚 发 现 

好 ) ， 通 过 不 在 HomeForSale 本 身 中 声明 copy constructor (H W438 ERX) 和 copy 
assignment operator (拷贝 赋值 运算 符 ) 为 priyate: 而 是 在 一 个 为 prevent copying (防止 找 
n) 而 特意 设计 的 base class ( 基 类 ) 中 声明 。 这 个 base class ( 基 类 ) 本 身 非常 简单 : 


class Uncopyable { 


protected: // allow construction 
Uncopyable() {} // and destruction of 
~Uncopyable() {} // derived objects... 

private: 
Uncopyable(const Uncopyable&) ; // ...but prevent copying 
Uncopyable& operator=(const Uncopyable&) ; 

J; 


为 了 阻止 拷贝 HomeForSale objects (xt&) ， 我 们 现在 必须 让 它 从 Uncopyable 继承 : 


class HomeForSale: private Uncopyable { // class no longer 
BF Ae // declares copy ctor or 
jap // copy assign. operator 


这 样 做 是 因为 ， 如 果 有 人 一 一 其 至 是 member (MA 
图 拷贝 一 个 HomeForSale objects (对 象 ) ， 编 > 个 copy constructor Pe 
HERA) 和 一 个 copy assignment operator (拷贝 赋值 运算 符 ) . MR Item 12 解释 的 ， 这 
tZ compiler-generated versions 〈 编 译 器 生成 版 ) 会 试图 调用 base class (26%) 的 相 
应 函数 ， 而 这 些 调用 将 被 拒绝 ， 因 为 在 base class ( 基 类 ) 中 ， 找 贝 操作 是 private (私有 ) 
的 。 





Uncopyable 的 实现 和 使 用 包含 一 些微 妙 之 处 ， 上 比如 ， 从 Uncopyable 继承 不 必 是 public (4 
有 ) 的 (参见 Item 32 和 39) ， 而 且 Uncopyable 的 destructor ( 析 构 函数 ) 不 必 是 

virtual (虚拟 ) 的 (参见 ltem 7) 。 因 为 Uncopyable 不 包含 数据 ， 所 以 它 符合 ltem 39 描述 
BY empty base class optimization ( 空 基 类 优化 ) 的 条 件 ， 但 因为 它 是 base class ( 基 类 ) ， 
此 项 技术 的 应 用 不 能 引入 multiple inheritance (多 继承 ) (参见 ltem 40) 。 反 过 来 说 ， 
multiple inheritance (多 继承 ) 有 时 会 使 empty base class optimization ( 空 基 类 优化 ) 失效 
(还 是 参见 Item 39) 。 通 常 ， 你 可 以 忽略 这 些微 妙 之 处 ， 而 且 仅 仅 像 此 处 演示 的 这 样 来 使 用 
Uncopyable， 因 为 它 的 工作 就 像 在 做 广告 。 你 还 可 以 使 用 在 Boost (参见 ltem 55) 中 的 一 个 
可 用 版 本 。 那 个 class (类 ) 名 为 noncopyable。 那 是 一 个 好 东西 ， 我 只 是 发 现 那 个 名 字 有 点 
儿 un- (不 ......) %&...... nonnatural ( 非 自 然 ) 。 


Things to Remember 


。 为 了 拒绝 编译 器 自动 提供 的 机 能 ， 将 相应 的 member functions (AK ARR) 声明 为 
private， 而 且 不 要 给 出 implementations (实现 ) 。 使 用 一 个 类 似 Uncopyable 的 base 
class ( 基 类 ) 是 方法 之 一 。 


Item 7: 4 polymorphic base classes (444 
类 ) 中 将 destructors (MARZ) 声明 为 
virtual (虚拟 ) 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


有 很 多 方法 取得 时 间 ， 所 以 有 必要 建立 一 个 TimeKeeper base class ( 基 类 ) ， 并 为 不 同 的 计 
时 方法 建立 derived classes (派生 类 ) 


class TimeKeeper { 

public: 
TimeKeeper(); 
~TimeKeeper(); 


a 
class AtomicClock: public TimeKeeper { ... }; 
class WaterClock: public TimeKeeper { ... }; 
class WristWatch: public TimeKeeper { ... }; 


很 多 客户 只 是 想 简单 地 取得 时 间 而 不 关心 如 何 计算 的 细节 ， 所 以 一 个 factory function (工厂 
KA) 一 一 返回 a base class pointer to a newly-created derived class object (一 个 指向 新 建 
派生 类 对 象 的 基 类 指针 ) 的 函数 一 一 可 以 被 用 来 返回 一 个 指向 timekeeping object (计时 对 
象 ) 的 指针 : 





TimeKeeper* getTimeKeeper(); // returns a pointer to a dynamic- 
// ally allocated object of a class 
// derived from TimeKeeper 


4 factory function (工厂 函数 ) 的 惯例 一 致 ，getTimeKeeper 返回 的 objects (对 象 ) 是 建立 
在 heap (H) 上 的 ， 所 以 为 了 避免 泄漏 内 存 和 其 它 资 源 ， 每 一 个 返回 的 objects (对 象 ) 被 
完全 deleted 是 很 重要 的 。 


TimeKeeper *ptk = getTimeKeeper(); // get dynamically allocated object 
// from TimeKeeper hierarchy 


// use it 


delete ptk; // release it to avoid resource leak 


Item 13 解释 了 为 什么 依赖 客户 执行 删除 任务 是 error-prone (错误 倾向 ) , Item 18 解释 了 
factory function (LT Wt) 的 interface (接口 ) 应 该 如 何 改变 以 防止 普通 的 客户 错误 ， 但 这 
些 在 这 里 都 是 次 要 的 ， 因 为 在 这 个 ltem 中 ， 我 们 将 精力 集中 于 上 面 的 代码 中 一 个 更 基本 的 缺 
陷 : 即使 客户 做 对 了 每 一 件 事 ， 也 无 法 预知 程序 将 如 何 运转 。 


问题 在 于 getTimeKeeper 返回 一 个 pointer to a derived class object (指向 派生 类 对 象 的 指 
$+) (HEAD AtomicClock) ， 那 个 object 〈 对 象 ) 经 由 一 个 base class pointer ( 基 类 指针 ) 

(也 就 是 一 个 TimeKeeper pointer) 被 删除 ， 而 且 这 个 base class (46%) (TimeKeeper) 有 
一 个 non-virtual destructor (JER AMT ABR) 。 祸 端 就 在 这 里 ， 因 为 C++ 规定 : 当 一 个 
derived class object (派生 类 对 象 ) 通过 使 用 一 个 pointer to a base class with a non-virtual 
destructor (指向 带 有 非 虚拟 析 构 函数 的 基 类 的 指针 ) 被 删除 ， 则 结果 是 未 定义 的 。 运 行 时 比 
较 典 型 的 后 果 是 derived part of the object (这 个 对 象 的 派生 部 分 ) 不 会 被 析 构 。 如 果 
getTimeKeeper 返回 一 个 指向 AtomicClock object (xt) 的 指针 ， 则 object (对 象 ) 的 
AtomicClock 部 分 (也 就 是 在 AtomicClock class 中 声明 的 data members (数据 成 员 ) ) 很 
可 能 不 会 被 析 构 ，AtomicClock 的 destructor ( 析 构 函数 ) 也 不 会 运行 。 然 而 ，base class 
part 〈 基 类 部 分 ) (也 就 是 TimeKeeper 部 分 ) 很 可 能 已 被 析 构 ， 这 就 导致 了 一 个 古怪 的 
"partially destroyed" object (“部 分 被 析 构 "对象 ;。 这 是 一 个 导致 泄漏 资源 ， 破 坏 数 据 结构 以 
及 消耗 大 量 调试 时 间 的 绝妙 方法 。 


消除 这 个 问题 很 简单 : 给 base class 〈 基 类 ) 一 个 virtual destructor (E WIRK) o F 
是 ， 删 除 一 个 derived class object (派生 类 对 象 ) 的 时 候 就 有 了 你 所 期 望 的 行为 。 将 析 构 
entire object (整个 对 象 ) ， 包 括 全 部 的 derived class parts (派生 类 构件 ) 


class TimeKeeper { 
public: 

TimeKeeper(); 

virtual ~TimeKeeper(); 


a 


TimeKeeper *ptk = getTimeKeeper(); 
delete ptk; // now behaves correctly 


类 似 TimeKeeper 的 base classes ( 基 类 ) 一 般 都 包含 除了 destructor (THR) 以 外 的 其 
© virtual functions (虚拟 画 数 ) ， 因 为 virtual functions (wh) 的 目的 就 是 允许 
derived class implementations (派生 类 实现 ) 的 定制 化 (参见 Item 34) 。 例 如 ， 
TimeKeeper 可 以 有 一 个 virtual functions (虚拟 函数 ) getCurrentTime， 它 在 各 种 不 同 的 
derived classes (派生 类 ) 中 有 不 同 的 实现 。 几 乎 所 有 拥有 virtual functions (HWA) 的 
class (#) 差不多 都 应 该 有 一 个 virtual destructor (Epi ARR) 。 


如 果 一 个 class (类 ) 不 包含 virtual functions (虚拟 函数 ) ， 这 经 常 预示 不 打算 将 它 作 为 
base class ( 基 类 ) 使 用 。 当 一 个 class (类 ) 不 打算 作为 base class ( 基 类 ) 时 ， 将 
destructor (4H) 虚拟 通常 是 个 坏 主意 。 考 虑 一 个 表现 二 维 空间 中 的 点 的 


class (#) 


class Point { // a 2D point 
public: 

Point(int xCoord, int yCoord); 

~Point(); 


private: 
int x, y; 


如 果 一 个 int 占用 32 bits， 一 个 Point object 正好 适用 于 64-bit 的 寄存 器 。 而 且 ， 这 样 一 个 
Point object 可 以 被 作为 一 个 64-bit 的 量 传递 给 其 它 语言 写 的 酚 数 ， 比 如 C 或 者 FORTRAN. 
如 果 Point 的 destructor (WARO 被 虚拟 ， 情 况 就 完全 不 一 样 了 。 


virtual functions (EPRA) 的 实现 要 求 object (tk) 携带 额外 的 信息 ， 这 些 信息 用 于 在 运 
行 时 确定 该 object (对 象 ) 应 该 调用 哪 一 个 virtual functions (虚拟 函数 ) 。 典 型 情况 下 ， 这 
一 信息 具有 一 种 被 称 为 vptr (“virtual table pointer") (虚拟 函数 表 指 针 ) 的 指针 的 形式 。vptr 
指向 一 个 被 称 为 vtbl ("virtual table") 〈 虚 拟 函 数 表 ) 的 array of function pointers (函数 指针 数 
ta) ， 每 一 个 带 有 virtual functions 〈 虚 拟 函 数 ) 的 class (类 ) 都 有 一 个 相关 联 的 vtbl。 当 在 
一 个 object (对 象 ) 上 调用 virtual functions (Hm) at, KN RIA ARBOR FRY 
步骤 确定 : 找到 object 〈 对 象 ) 的 vptr 指向 的 vtbl， 然 后 在 vtbl 中 寻找 合适 的 function 
pointer (HAE) 。 


virtual functions (EWR) 是 如 何 实现 的 细节 并 不 重要 。 重 要 的 是 如 果 Point class 包含 一 
个 virtual functions (虚拟 画 数 ) ， 这 个 类 型 的 object (对 象 ) 的 大 小 就 会 增加 。 在 一 个 32- 
bit 架构 中 ， 它 们 将 从 64 bits (相当 于 两 个 ints) 长 到 96 bits (两 个 ints 加 上 vptr) ; 在 一 个 
64-bit 架构 中 ， 它 们 可 能 从 64 bits 长 到 128 bits， 因 为 在 这 样 的 架构 中 指针 的 大 小 是 64 bits 
的 。 为 Point 加 上 vptr 将 会 使 它 的 大 小 增长 50-100% ! Point object (对 象 ) 不 再 适合 64-bit 
寄存 器 。 而 且 ，Point object (对 象 ) 在 C++ 和 其 它 语言 (比如 C) 中 ， 看 起 来 不 再 具有 相同 
的 结构 ， 因 为 它们 在 其 它 语 言 中 的 对 应 物 没 有 vptr。 oe Points 不 再 可 能 传人 其 它 语言 写 
成 的 函数 或 从 其 中 传 出 ， 除 非 你 为 vptr 做 出 明确 的 补偿 ， 它 自 己 的 实现 细节 并 因此 失 
去 可 移植 性 。 


最 终结 果 就 是 无 故地 将 所 有 destructors (ATEN) 声明 为 virtual (虚拟 ) ， 和 从 不 把 它们 
声明 为 virtual (虚拟 ) 一 样 是 错误 的 。 实 际 上 ， 很 多 人 总 结 过 这 条 规则 : declare a virtual 
destructor in a class if and only if that class contains at least one virtual function 〈 当 且 公 当 
一 个 类 中 包含 至 少 一 个 虚拟 函数 时 ， 则 在 类 中 声明 一 个 虚拟 析 构 函数 ) 。 


甚至 在 完全 没有 virtual functions (HMB) 时 ， 也 有 可 能 纠缠 于 non-virtual destructor (JE 
虚拟 析 构 男 数 ) 问题 。 例 如 ， 标 准 string 类 型 不 包含 virtual functions (虚拟 函数 ) ， 但 是 被 
误导 的 程序 员 有 时 将 它 当 作 base class ( 基 类 ) 使 用 : 


class SpecialString: public std::string { // bad idea! std::string has a 
oar // non-virtual destructor 
3; 


一 眼看 上 去 ， 这 可 能 无 伤 大 雅 ， 但 是 ， 如 果 在 程序 的 某 个 地 方 因为 某 种 原因 ， 你 将 一 
pointer-to-SpecialString (指向 SpecialString 的 指针 ) 转型 为 一 个 pointer-to-string (指向 
string 的 指针 ) ， 然 后 你 将 delete 施加 于 这 个 string pointer (指针 ) ， 你 就 立刻 被 放逐 到 
undefined behavior (未 定义 行为 ) 的 领地 : 


SpecialString *pss = new SpecialString("Impending Doom"); 
std::string *ps; 
ps = pss; // SpecialString* > std::string* 
delete ps; // undefined! In practice, 
// *ps's SpecialString resources 
// will be leaked, because the 


// SpecialString destructor won't 
// be called. 


M4 BT LS AF aR virtual destructor (虚拟 析 构 男 数 ) 的 class (类 ) ， 包 括 全 
部 的 STL container (容器 ) 类 型 (例如 ，vector，list，set，tr1::unordered_map (参见 Item 
54) 等 ) 。 如 果 你 受到 从 standard container (标准 容器 ) 或 任何 其 它 带 有 non-virtual 
destructor (JERR a ATH ENE) 的 class 〈 类 ) 继承 的 诱惑 ， 一 定 要 挺 住 ! 〈 不 幸 的 是 ，C++ 
不 提供 类 似 Java 的 final classes (#) 或 C# 的 sealed classes (类 ) 的 derivation- 
prevention mechanism ( 防 派生 机 制 ) 。) 


有 时 候 ， 给 一 个 class (类 ) 提供 一 个 pure virtual destructor ( 纯 虚 拟 析 构 画 数 ) 能 提供 一 些 
便利 。 回 想 一 下 ，pure virtual functions 〈 纯 虚拟 函 数 ) 导致 abstract classes eee 一 一 
不 能 被 实例 化 的 classes (类 ) (也 就 是 说 你 不 能 创建 这 个 类 型 的 objects (stk) ) 。 

而 ， 有 时 候 ， 你 有 一 个 class (类 ) ， 你 希望 它 是 抽象 的 ， 但 没有 任何 pure virtual 

functions (EWK) 。 怎 么 办 呢 ?因为 一 个 abstract classes (抽象 类 ) 注定 要 被 用 作 
base class ( 基 类 ) ， 又 因为 一 个 base class ( 基 类 ) 应 该 有 一 个 virtual destructor (虚拟 析 
构 范 数 ) ， 还 因为 一 人 pute virtual functions (4,2 E42) 产生 一 个 abstract classes (Hh 
象 类 ) ， 好 了 ， 解 决 方案 很 简单 : 在 你 想 要 变 成 抽象 的 class (类 ) 中 声明 一 个 pure virtual 
destructor aa 。 这 是 一 个 例子 : 


class AWOV { // AWOV = "Abstract w/o Virtuals" 
public: 

virtual ~AWOV() = 0; // declare pure virtual destructor 
}; 


这 个 class (#) 有 一 个 pure virtual functions 〈 纯 虚拟 函数 ) ， 所 以 它 是 抽象 的 ， 又 因为 它 
有 一 个 virtual destructor (Ea MATHER) ， 所 以 你 不 必 担 心 析 构 函数 问题 。 这 是 一 个 螺旋 。 
然而 ， 你 必须 为 pure virtual destructor (EWIT ABR) 提供 一 个 definition (定义 ) 


AWOV: :~AWOV() {} // definition of pure virtual dtor 


destructors ( 析 构 函数 ) 的 工作 方式 是 : most derived class (层次 最 低 的 派生 类 ) 的 
destructor (AKZO 最 先 被 调用 ， 然 后 调用 每 一 个 base class 〈 基 类 ) 的 destructors ( 析 
HAA) 。 编 译 器 会 生成 一 个 从 它 的 derived classes (派生 类 ) 的 destructors ( 析 构 函数 ) 
对 ~AWOV 的 调用 ， 所 以 你 不 得 不 确保 为 函数 提供 一 个 函数 体 。 如 果 你 不 这 样 做 ， 连 接 程 序 
会 提出 抗议 。 


为 base classes ( 基 类 ) 提供 virtual destructor (HEATH) 的 规则 仅仅 适用 于 
polymorphic base classes (多 态 基 类 ) 一 一 base classes ( 基 类 ) 被 设计 成 允许 通过 base 
class interfaces ( 基 类 接口 ) 对 derived class types (派生 类 类 型 ) 进行 操作 。TimeKeeper 
就 是 一 个 polymorphic base classes (多 态 基 类 ) ， 因 为 即使 我 们 只 有 类 型 为 TimeKeeper 的 
pointers (指针 ) 指向 它们 的 时 候 ， 我 们 也 期 望 能 够 操作 AtomicClock 和 WaterClock 
objects (xt&) 。 


并 非 所 有 的 base classes ( 基 类 ) 都 被 设计 用 于 polymorphically (4A) 。 例 如 ， 无 论 是 
standard string type (标准 string 类 型 ) ， 还 是 STL container types (STL 容器 类 型 ) 全 被 
设计 成 base classes ( 基 类 ) ， 可 没有 哪个 是 polymorphic (多 态 ) 的 。 一 些 classes (类 ) 
虽然 被 设计 用 于 base classes ( 基 类 ) ， 但 并 非 被 设计 用 于 polymorphically (SA) 。 这 样 
的 classes (类 ) 一 一 例如 Item 6 中 的 Uncopyable 和 标准 库 中 的 input_ iterator tag (参见 
ltem 47) 没有 被 设计 成 允许 经 由 base class interfaces ( 基 类 接口 ) 对 derived class 
objects (派生 类 对 象 ) 进行 操作 。 所 以 它们 就 不 需要 virtual destructor (虚拟 析 构 函数 ) 。 





Things to Remember 


e polymorphic base classes (多 态 基 类 ) 应 该 声明 virtual destructor (虚拟 析 构 图 数 ) 。 
如 果 一 个 class (类 ) 有 任何 virtual functions (虚拟 函数 ) ， 它 就 应 该 有 一 个 virtual 
destructor (kz MAT HEEL) 。 


。 不 是 设计 用 来 作为 base classes (4%) 或 不 是 设计 用 于 polymorphically (2A) 的 
classes (类 ) 就 不 应 该 声明 virtual destructor (虚拟 析 构 范 数 ) 。 


Item 8: 防止 因为 exceptions (异常 ) 而 离开 
destructors (HTZ) 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


C++ 并 不 禁止 从 destructors (HER) 中 引发 exceptions (异常 )， 但 是 它 坚 决 地 阻止 这 
样 的 实践 。 至 于 有 什么 好 的 理由 ， 考 虑 : 


class Widget { 
public: 


~Widget() { ... } // assume this might emit an exception 


void doSomething() 
std::vector<wWidget> v; 


} // Vv is automatically destroyed here 


4 vector v 被 析 构 时 ， 它 有 责任 析 构 它 包 含 的 所 有 Widgets. (Rik v 中 有 十 个 Widgets, 4% 
一 个 的 析 构 过 程 中 ， 抛 出 一 个 exception (F) 。 其 它 9 个 Widgets 仍然 必须 被 析 构 (否则 
它们 持 有 的 所 有 资源 将 被 泄漏 ) ， 所 以 v 应 该 调用 它们 的 destructors TARZ) 。 但 是 假 
设 在 这 个 调用 期 间 ， 第 二 个 Widget 的 destructors ( 析 构 函数 ) 又 抛 出 一 个 exception (F 
常 )。 现 在 同时 有 两 个 活动 的 exceptions (异常 )， 对 于 C++ 来 说 ， 这 太 多 了 。 人 在 非常 巧合 
的 条 件 下 产生 这 样 两 个 同时 活动 的 异常 ， 程 序 的 执行 会 终止 或 者 引发 undefined behavior (未 
定义 行为 ) 。 在 本 例 中 ， 将 引发 undefined behavior (未 定义 行为 ) 。 使 用 任何 其 它 的 标准 库 
container (容器 ) (EAN, list, set) ， 任 何 TR1 (参见 Item 54) 中 的 container (容器 ) , 
甚至 是 一 个 array 〈 数 组 ) ， 都 可 能 会 引发 同样 的 undefined behavior (未 定义 行为 ) 。 也 并 
非 必须 是 containers (容器 ) 或 arrays (数组 ) 才 会 陷入 麻烦 。 程 序 过 早 终止 或 undefined 
behavior (未 定义 行为 ) 是 destructors (HTH) 引发 exceptions (HA) 的 结果 ， 即 使 
没有 使 用 containers (容器 ) 和 arrays (数组 ) 也 会 如 此 。C++ 不 喜欢 引发 exceptions (= 
常 ) 的 destructors (WAER) 。 


这 比较 容易 理解 ， 但 是 如 果 你 的 destructor (AHN) 需要 执行 一 个 可 能 失败 而 抛 出 一 个 
exception (异常 ) 的 操作 ， 该 怎么 办 呢 ? 例如， 假设 你 与 一 个 数据 库 连 接 类 一 起 工作 : 


class DBConnection { 


public: 
static DBConnection create(); // function to return 
// DBConnection objects; params 
// omitted for simplicity 
void close(); // close connection; throw an 
}; // exception if closing fails 


为 了 确保 客户 不 会 忘记 在 DBconnection objects (对 象 ) 上 调用 close， 一 个 合理 的 主意 是 为 
DBConnection 建立 一 个 resource-managing class (资源 管理 类 ) ， 在 它 的 destructor ( 析 构 
KA) 中 调用 close。 这 样 的 resource-managing classes (资源 管理 类 ) 将 在 Chapter 3 (第 
三 章 ) 中 一 探究 竟 ， 但 在 这 里 ， 只 要 认为 这 样 一 个 class (类 ) 的 destructor GRAKO 看 
起 来 像 这 样 就 足够 了 : 


class DBConn { // Class to manage DBConnection 
public: // objects 
~DBConn() // make sure database connections 


// are always closed 
db.close(); 


private: 
DBConnection db; 


ten 


它 人 允许 客户 像 这 样 编程 : 


// open a block 
DBConn dbc(DBConnection::create()); // create DBConnection object 

// and turn it over to a DBConn 
// object to manage 
// use the DBConnection object 
// via the DBConn interface 

} // at end of block, the DBConn 
// object is destroyed, thus 
// automatically calling close on 
// the DBConnection object 


只 要 能 成 功 地 调用 close 就 可 以 了 ， 但 是 如 果 这 个 调用 导致 一 个 exception (异常 ) ， 
DBConn 的 destructor (WARO 将 传播 那个 exception (异常 ) ， 也 就 是 说 ， 它 将 离开 
destructor 〈 析 构 范 数 ) 。 这 就 产生 了 问题 ， 因 为 destructor (HH) 抛 出 了 一 个 学 手 的 
山芋 。 


有 两 个 主要 的 方法 避免 这 个 麻烦 。DBConn 的 destructor ( 析 构 函数 ) 能 : 


e Terminate the program if close tHRows (#058 close 抛 出 异常 就 终止 程序 ) ， 一 般 是 通 
过 调用 abort : 


DBConn: :~DBConn( ) 


{ 
try { db.close(); } 
catch (...) { 
make log entry that the call to close failed; 
std::abort(); 
} 
} 


如 果 在 析 构 的 过 程 遭 遇 到 错误 后 程序 不 能 继续 运行 ， 这 就 是 一 个 合理 的 选择 。 它 有 一 个 好 义 
是 : 如 果 人 允许 从 destructor GARR) 传播 exception (FH) 可 能 会 导致 undefined 
behavior (未 定义 行为 ) ， 这 样 就 能 防止 它 发 生 。 也 就 是 说 ， 调 用 abort 就 可 以 预先 防止 
undefined behavior (未 定义 行为 ) 。 


e Swallow the exception arising from the call to close (抑制 这 个 对 close 的 调用 造成 的 异 
常 ) 


DBConn: :~DBConn() 


{ 
try { db.close(); } 
catch (...) { 
make log entry that the call to close failed; 
} 
} 





14%, swallowing exceptions (抑制 异常 是 一 个 不 好 的 主意 ， 因 为 它 会 隐瞒 重要 的 信息 
something failed 〈 某 事 失 败 了 ) ! 然而， 有些 时 候 ，swallowing exceptions (抑制 异常 ) 上 比 
冒 程序 过 早 终止 或 undefined behavior (未 定义 行为 ) 的 风险 更 可 取 。 程 序 必 须 能 够 在 遭遇 到 
一 个 错误 并 忽略 之 后 还 能 继续 可 靠 地 运行 ， 这 才能 成 为 一 个 可 行 的 选择 。 


这 些 方法 都 不 太 吸 引 人 。 它 们 的 问题 首先 在 于 程序 无 法 对 引起 close 抛 出 exception (异常 ) 
的 条 件 做 出 回应 。 


一 个 更 好 的 策略 是 设计 DBConn 的 interface (接口 ) ， 以 使 它 的 客户 有 机 会 对 可 能 会 发 生 的 
问题 做 出 回应 。 例 如 ，DBConn 能 够 自己 提供 一 个 close 画 数 ， 从 而 给 客户 一 个 机 会 去 处 理 
从 那个 操作 中 发 生 的 exception (异常 )。 它 还 能 保持 对 它 的 DBConnection 是 否 已 被 closed 
的 跟踪 ， 如 果 没 有 就 在 destructor 〈 析 构 范 数 ) 中 自己 关闭 它 。 这 样 可 以 防止 连接 被 泄漏 。 如 
果 在 DBConnection (原文 如 此 ， 严 重 怀疑 此 处 应 为 DBConn 一 一 译 者 注 ) 的 destructor (HT 
WBN) 中 对 cose 的 调用 失败 ， 无 论 如 何 ， 我 们 还 可 以 再 返回 到 终止 或 者 抑制 。 


class DBConn { 
public: 


void close() // new function for 

{ // client use 
db.close(); 

closed = true; 


~DBConn() 
if (!closed) { 
try { // close the connection 
db.close(); // if the client didn't 
} 
catch (...) { // if closing fails, 
make log entry that call to close failed; // note that and 
Tan // terminate or swallow 
} 
} 
private: 


DBConnection db; 
bool closed; 


J; 


将 调用 close 的 责任 从 DBConn 的 destructor (ARRO 移交 给 DBConn 的 客户 (同时 在 
DBConn 的 destructor (#74) 中 包含 一 个 “候补 "调用 ) 可 能 会 作为 一 种 肆 无 尽 翌 地 推卸 
责任 的 做 法 而 使 你 吃惊 。 你 甚至 可 以 把 它 看 作对 Item 18 中 关于 使 interfaces (接口 ) 易于 正 
确 使 用 的 建议 的 违背 。 实 际 上 ， 这 都 不 正确 。 如 果 一 个 操作 可 能 失败 而 抛 出 一 个 

exception (异常 ) ， 而 且 可 能 有 必要 义理 这 个 exception (异常 ) ， 这 个 exception (异常 ) 
就 has to come from some non-destructor function (必须 来 自 非 析 构 函数 ) 。 这 是 因为 
destructor (RŽ) 引发 exception (异常 ) 是 危险 的 ， 永 远 都 要 冒 着 程序 过 早 终止 或 
undefined behavior (RELTA) 的 风险 。 在 本 例 中 ， 让 客户 自己 调用 close 并 不 是 强加 给 
他 们 的 负担 ， 而 是 给 他 们 一 个 时 机 去 应 付 错误 ， 否 则 他 们 将 没有 机 会 做 出 回应 。 如 果 他 们 找 
不 到 可 用 到 机 会 (或许 因为 他 们 相信 不 会 有 错误 真 的 发 生 ) ， 他 们 可 以 忽略 它 ， 依 靠 
DBConn 的 destructor (ARRO 为 他 们 调用 close。 如 果 一 个 错误 恰恰 在 那 时 发 生 一 一 如 
果 由 close 抛 出 一 一 如 果 DBConn 抑制 了 那个 exception (异常 ) 或 者 终止 了 程序 ， 他 们 将 无 
处 诉苦 。 半 况 ， 他 们 无 处 着 手 处 理 问题 ， 他 们 将 不 再 使 用 它 。 


Things to Remember 


e destructor (HEZO 应 该 永 不 引发 exceptions (HH) 。 如 果 destructor (At HH 
数 ) 调用 了 可 能 抛 出 异常 的 函数 ，destructor ( 析 构 函数 ) 应 该 捕捉 所 有 异常 ， 然 后 抑制 
它们 或 者 终止 程序 。 


e 如 果 class (类 ) 客户 需要 能 对 一 个 操作 抛 出 的 exceptions (F) 做 出 回应 ， 则 那个 
class (#) 应 该 提供 一 个 常规 的 函数 〈 也 就 是 说 ，non-destructor (FEATHER) ) 来 完 
成 这 个 操作 。 


Item 9: 244-224 construction (构造 ) 或 
destruction (#174) 期 间 调用 virtual 
functions (虚拟 函数 ) 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


我 以 这 个 概述 开始 : 你 不 应 该 在 construction (构造 ) 或 destruction ( 析 构 ) 期 间 调 用 virtual 
functions (zw) ， 因 为 这 样 的 调用 不 会 如 你 想象 那样 工作 ， 而 且 它 们 做 的 事情 保证 会 
让 你 很 郁闷 。 如 果 你 转 为 Java 或 C# 程序 员 ， 也 请 你 密切 关注 本 Item, HAE C++ ARS 
的 地 方 ， 那 些 语言 也 紧急 转 了 一 个 弯 。 


假设 你 有 一 套 模拟 股票 交易 的 class hierarchy (类 继承 体系 ) ， 例 如 ， 购 入 订单 ， 出 售 订 单 
等 。 对 于 这 样 的 交易 来 说 可 供 审查 是 非常 重要 的 ， 所 每 次 一 个 交易 对 象 被 创建 ， 在 一 个 审查 
日 志 中 就 需要 创建 一 个 相应 的 条 目 。 下 面 是 一 个 看 起 来 似乎 合理 的 解决 问题 的 方法 : 


class Transaction { // base class for all 
public: // transactions 
Transaction(); 


virtual void logTransaction() const = 0; // make type-dependent 
// log entry 


J; 
Transaction: :Transaction() // implementation of 
{ // base class ctor 
logTransaction(); // as final action, log this 
} // transaction 
class BuyTransaction: public Transaction { // derived class 
public: 
virtual void logTransaction() const; // how to log trans- 
// actions of this type 
J; 
class SellTransaction: public Transaction { // derived class 
public: 
virtual void logTransaction() const; // how to log trans- 
// actions of this type 
J; 


考虑 执行 这 行 代码 时 会 发 生 什么 : 


BuyTransaction b; 


很 明显 一 个 BuyTransaction 的 constructor (构造 函数 ) 会 被 调用 ， 但 是 首先 ， 一 个 
Transaction 的 constructor (44316EN20) 必须 先 被 调用 ，derived class objects (派生 类 对 
象 ) 中 的 base class parts ( 基 类 构件 ) SEF derived class parts (派生 类 构件 ) 被 构造 。 
Transaction 的 constructor (44365521) 的 最 后 一 行 调用 virtual functions (E pR) 
logTransaction， 但 是 结果 会 让 你 大 吃 一 惊 ， 被 调用 的 logTransaction 版 本 是 在 Transaction 
中 的 那 一 个 ， 而 不 是 BuyTransaction 中 的 那 一 个 一 一 即使 被 创建 的 object (对 象 ) 类 型 是 
BuyTransaction。base class construction ( 基 类 构造 ) HAja, virtual functions (虚拟 函数 ) 
从 来 不 会 go down (向 下 匹配 ) 到 derived classes (派生 类 ) 。 取 而 代 之 的 是 ， 那 个 object 
GIR) 的 行为 好 像 它 就 是 base type ( 基 类 型 ) 。 非 正式 地 讲 ，base class 

construction ( 基 类 构造 ) 期 间 ，virtual functions (虚拟 函数 ) 被 禁止 。 


这 个 表面 上 看 起 来 匪夷所思 的 行为 存在 一 个 很 好 的 理由 。 因 为 base class constructors (4 # 
DERA) 在 derived class constructors (派生 类 构造 男 数 ) 之 前 执行 ， 当 base class 
constructors ( 基 类 构造 画 数 ) 运行 时 ，derived class data members (派生 类 数据 成 员 ) 还 
没有 被 初始 化 。 如 果 base class construction ( 基 类 构造 ) 期 间 virtual functions (虚拟 函数 ) 
的 调用 went down (向 下 匹配 ) 到 derived classes (派生 类 ) , derived classes (派生 类 ) 
的 函数 差不多 总 会 涉及 到 local data members (局 部 数据 成 员 ) ， 但 是 那些 data 

members (数据 成 员 ) 至 此 还 没有 被 初始 化 。 这 就 会 为 undefined behavior (未 定义 行为 ) 
和 通 滑 达 且 的 调试 重 梦 开 了 一 张 通行 证 。 调 用 涉及 到 一 个 object (GR) 还 没有 被 初始 化 的 
构件 自然 是 危险 的 ， 所 以 C++ 告诉 你 此 路 不 通 。 


实际 上 还 有 比 这 更 基本 的 原理 。 在 一 个 derived class object (派生 类 对 象 ) 的 base class 
construction 〈 基 类 构造 ) 期 间 ，object 〈 对 象 ) 的 类 型 是 base class ( 基 类 ) 的 类 型 。 不 仅 
virtual functions (虚拟 函数 ) 会 解析 到 base class ( 基 类 ) ， 而 且 用 到 runtime type 
information (运行 时 类 型 信息 ) 的 语言 构件 〈 例 如 ，dynamic_cast (参见 Item 27) 和 
typeid) ， 也 会 将 那个 object (对 象 ) 视 为 base classtype ( 基 类 类 型 ) 。 在 我 们 的 例子 中 ， 
当 Transaction 的 constructor GARZO 运行 到 初始 化 一 个 BuyTransaction object (xt 
R) 的 base class ( 基 类 ) 部 分 时 ， 那 个 object (对 象 ) 的 是 Transaction 类 型 。C++ 的 每 一 
个 构件 将 以 如 下 眼光 来 看 待 它 ， 而 且 这 种 看 法 是 合理 的 : 这 个 object (对 象 ) 的 
BuyTransaction-specific 的 构件 还 没有 被 初始 化 ， 所 以 对 它们 视 若 无 睹 是 最 安全 的 。 直 到 
derived class constructor (派生 类 构造 豆 数 ) 的 执行 开始 之 前 ， 一 个 object (tk) 不 会 成 
为 一 个 derived class object (派生 类 对 象 ) 。 


同样 的 推理 也 适用 于 destruction ( 析 构 ) 。 一 且 derived class destructor GRE # #14 
数 ) 运行 ， 这 个 object (对 象 ) 的 derived class data members (派生 类 数据 成 员 ) 就 呈现 为 
未 定义 的 值 ， 所 以 C++ 就 将 它们 视 为 不 再 存在 。 在 进入 base class destructor (2 # #1 4H 
数 ) 时 ， 这 个 object (对 象 ) 就 成 为 一 个 base class object ( 基 类 对 象 ) , C++ 的 所 有 构件 
— virtual functions (虚拟 函数 ) , dynamic_casts 等 一 一 都 以 此 看 待 它 。 


在 上 面 的 示例 代码 中 ，Transaction 的 constructor (构造 画 数 ) 造成 了 对 一 个 virtual 
functions (PW) 的 一 次 直接 调用 ， 是 对 本 Item 的 指导 建议 的 显而易见 的 违背 。 这 一 违 
背 是 如 此 显 见 ， 以 致 一 些 编译 器 会 给 出 一 个 关于 它 的 警告 。 ( 另 一 些 则 不 会 。 参 见 Item 53 对 


于 警告 的 讨论 。) 即使 没有 这 样 的 一 个 警告 ， 这 个 问题 也 几乎 肯定 会 在 运行 之 前 暴露 出 来 ， 
因为 logTransaction WIŠE Transaction 中 是 pure virtual ( 纯 虚 拟 ) 的 。 除 非 它 被 定义 (不 
太 可 能 ， 但 确实 可 能 一 一 参见 Item 34) ， 否 则 程序 将 无 法 连接 : 连接 程序 无 法 找到 
Transaction::logTransaction 的 必要 的 实现 。 





在 construction (构造 ) 或 destruction (#174) 期 间 调 用 virtual functions (虚拟 画 数 ) 的 问 
题 并 不 总 是 如 此 容易 被 察觉 。 如 果 Transaction 有 多 个 constructors (Mis HM) ， 每 一 个 都 
必须 完成 一 些 相同 的 工作 ， 软 件 工 程 为 避免 代码 重复 ， 将 共通 的 initialization (初始 化 ) 代 
码 ， 包 括 对 logTransaction 的 调用 ， 放 入 一 个 private non-virtual initialization function (私有 
非 虚拟 初始 化 函数 ) 中 ， 叫 做 init : 


class Transaction { 
public: 
Transaction() 
{ init(); } // call to non-virtual... 


virtual void logTransaction() const = 0; 


private: 
void init() 


logTransaction(); // ...that calls a virtual! 


} 
}; 


这 个 代码 在 概念 上 和 早先 那个 版 本 相同 ， 但 是 它 更 阴险 ， 因 为 一 般 来 说 它 会 艇 过 编译 器 和 连 
接 程 序 的 抱怨 。 在 这 种 情况 下 ， 因 为 logTransaction 在 Transaction 中 是 pure virtual ( 纯 虚 
BY) ， 在 pure virtual (4482) 被 调用 时 ， 大 多 数 runtime systems (运行 时 系统 ) 会 异常 中 止 
那个 程序 〈 一 般 会 对 此 结果 给 出 一 条 消息 ) 。 然 而 ， 如 果 logTransaction 在 Transaction 中 是 
一 个 "normal" virtual function (“常规 "虚拟 画 数 ) (也 就 是 说 ，not pure virtual ( 非 纯 虚拟 
的 ) ) ， 而 且 带 有 一 个 实现 ， 那 个 版 本 将 被 调用 ， 程 序 会 继续 一 路 小 跑 ， 让 你 想象 不 出 为 什 
么 在 derived class object (派生 类 对 象 ) 被 创建 的 时 候 会 调用 logTransaction 的 错误 版 本 。 
避免 这 个 问题 的 唯一 办 法 就 是 确保 你 的 constructors GAER) 或 destructors (TE 
数 ) 决 不 在 被 创建 或 析 构 的 object (sts) 上 调用 virtual functions (MAR) ， 它 们 所 调 
用 的 全 部 函数 也 要 服从 同样 的 约束 。 


但 是 ， 你 如 何 确保 在 每 一 次 Transaction hierarchy (继承 体系 ) 中 的 一 个 object (st KR) Hel 
建 时 ， 都 会 调用 logTransaction 的 正确 版 本 呢 ?显然 ， 在 Transaction constructor(s) (E 
数 ) 中 在 这 个 object (对 象 ) 上 调用 virtual functions (虚拟 函数 ) 的 做 法 是 错误 的 。 


有 不 同 的 方法 来 解决 这 个 问题 。 其 中 之 一 是 将 Transaction 中 的 logTransaction 转变 为 一 个 
non-virtual function ( 非 虚拟 函数 ) ， 这 就 需要 derived class constructors (派生 类 构造 画 
数 ) 将 必要 的 日 志 信息 传递 给 Transaction constructor (4368) 。 那 个 函数 就 可 以 安全 地 
调用 non-virtual ( 非 虚拟 ) 的 logTransaction。 如 下 : 


class Transaction { 
public: 
explicit Transaction(const std::string& logInfo); 


void logTransaction(const std::string& logInfo) const; // now a non- 
// virtual func 


J; 
Transaction: :Transaction(const std::string& logInfo) 
{ 
logTransaction(logInfo); // now a non- 
} // virtual call 
class BuyTransaction: public Transaction { 
public: 
BuyTransaction( parameters ) 
: Transaction(createLogString( parameters )) // pass log info 
to nae dp // to base class 
// constructor 
private: 
static std::string createLogString( parameters ); 
J; 


换 句 话说 ， 由 于 你 不 能 在 base classes ( 基 类 ) 的 construction (构造 ) 过 程 中 使 用 virtual 
functions (虚拟 函数 ) 向 下 匹配 ， 你 可 以 改 为 让 derived classes (派生 类 ) 将 必要 的 构造 信 
息 上 传 给 base class constructors ( 基 类 构造 函数 ) 作为 补偿 。 


在 此 例 中 ， 注 意 BuyTransaction 中 那个 (private) static 函数 createLogString 的 使 用 。 使 用 一 
个 辅助 画 数 创建 一 个 值 传递 给 base class constructors ( 基 类 构造 画 数 ) ， 通 常 比 通过 在 
member initialization list (成员 初始 化 列表 ) 给 base class ( 基 类 ) 它 所 需要 的 东西 更 加 便利 

(也 更 加 具有 可 读 性 ) 。 将 那个 函数 做 成 static， 就 不 会 有 偶然 触及 到 一 个 新 生 的 
BuyTransaction object (对 象 ) 的 as-yet-uninitialized data members 〈 仍 未 初始 化 的 数据 成 
A) 的 危险 。 这 很 重要 ， 因 为 实际 上 那些 data members (数据 成 员 ) 处 在 一 个 未 定义 状态 ， 
这 就 是 为 什么 在 base class ( 基 类 ) construction (构造 ) 和 destruction ( 析 构 ) 期 间 调用 
virtual functions (EMKA) 不 能 首先 向 下 匹配 到 derived classes (派生 类 ) 的 原因 。 


Things to Remember 


e 在 construction (4438) 或 destruction 〈 析 构 ) 期 间 不 要 调用 virtual functions (Ep 
数 ) ， 因 为 这 样 的 调用 不 会 转 到 比 当 前 执行 的 constructor (ARNA) 或 
destructor (TARO 所 属 的 class (类 ) 更 深层 的 derived class (派生 类 ) 。 


Item 10: 让 assignment operators (赋值 运算 
4) 返回 一 个 reference to *this ( 引 向 *this 的 引 
FA) 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


关于 assignments (赋值 ) 的 一 件 有 意思 的 事情 是 你 可 以 把 它们 穿 成 一 串 。 


另 一 件 有 意思 的 事情 是 assignment (赋值 ) 是 right-associative ( 右 结合 ) 的 ， 所 以 ， 上 面 的 
赋值 串 可 以 解析 成 这 样 : 


x = (y = (z = 15)); 


这 里 ，15 赋 给 z， 然 后 将 这 个 assignment (mia) 的 结果 (最 新 的 z) 赋 给 y， 然 后 将 这 个 
assignment (赋值 ) 的 结果 (最 新 的 y) KAA Xo 


这 里 的 实现 方法 是 让 assignment (赋值 ) 返回 一 个 reference to its left-hand argument ( 引 向 
它 的 左 侧 参数 的 引用 ) ， 而 且 这 就 是 当 你 为 你 的 classes (类 ) 实现 assignment 
operators (赋值 运算 符 ) 时 应 该 遵守 的 惯例 : 

class Widget { 

public: 


Widget& operator=(const Widget& rhs) // return type is a reference to 
// the current class 


return *this; // return the left-hand object 
} 


这 个 惯例 适用 于 所 有 的 assignment operators (赋值 运算 符 ) ， 而 不 仅仅 是 上 面 那样 的 标准 形 
式 。 因 此 : 


class Widget { 
public: 


Widget& operator+=(const Widget& rhs 


return *this; 


Widget& operator=(int rhs) 


return *this; 


} 
}; 


// 
// 


// 
// 
// 


the convention applies to 
+=, -=, *=, etc. 


了 ri 


it applies even if the 
operator's parameter type 
is unconventional 


这 仅仅 是 一 个 惯例 ， 代 码 并 不 会 按照 这 个 意愿 编译 。 然 而 ， 这 个 惯例 被 所 有 的 built-in 


types (内 建 类 型 ) 和 标准 库 中 (或 者 即将 进入 标准 库 





参见 Item 54) 的 types (类 型 ) 


(例如 ，string，vector，complex，tr1::shared_ptr 等 ) 所 遵守 。 除 非 你 有 好 的 做 不 同事 情理 


， 否则， 不 要 破坏 它 。 


Things to Remember 


e 让 assignment operators (赋值 运算 符 ) 返回 一 个 reference to *this ( 引 向 *this 的 引 


用 ) 。 


Item 11: Æ operator= 中 人 处理 assignment to 
self 〈 目 赋值 ) 


作者 : Scott Meyers 

译 者 : fatalerror99 (iTePub's Nirvana) 

发 布 : http://blog.csdn.net/fatalerror99/ 

当 一 个 object (QR) 赋值 给 自己 的 时 候 就 发 生 了 一 次 assignment to self ( 自 赋值 ) 
class Widget { ... }; 
Widget w; 


W=w; // assignment to self 


这 看 起 来 很 思春 ， 但 它 是 合法 的 ， 所 以 应 该 确信 客户 会 这 样 做 。 另 外 ，assignment 〈 赋 值 ) 
也 并 不 总 是 那么 容易 辨别 。 例 如 ， 


a = a[j]; // potential assignment to self 


如 果 i 和 j 有 同样 的 值 就 是 一 个 assignment to self ( 自 赋 值 ) ， 还 有 


*px = *py; // potential assignment to self 


如 果 px 和 py 碰巧 指向 同一 个 东西 ， 这 也 是 一 个 assignment to self 〈 自 赋值 ) 。 这 些 不 太 明 
显 的 assignments to self (A w4) 是 由 aliasing (别名 ) 〈 有 不 止 一 个 方法 引用 一 个 

object (对 象 ) ) 造成 的 。 通 常 ， 使 用 references (引用 ) 或 者 pointers (指针 ) 操作 相同 类 
型 的 多 个 objects (对 象 ) 的 代码 需要 考虑 那些 objects (对 象 ) 可 能 相同 的 情况 。 实 际 上 ， 如 
RAA objects (对 象 ) 来 自 同 一 个 hierarchy (继承 体系 ) ， 甚 至 不 需要 公开 声明 ， 它 们 就 是 
相同 类 型 的 ， 因 为 一 个 base class ( 基 类 ) 的 reference (引用 ) 或 者 pointer (指针 ) 也 能 够 
引 向 或 者 指向 一 个 derived class (派生 类 ) 类 型 的 object (对 象 ) 


class Base { ... }; 
class Derived: public Base { ... }; 


void doSomething(const Base& rb, // rb and *pd might actually be 
Derived* pd); // the same object 


如 果 你 遵循 Item 13 和 14 的 建议 ， 你 应 该 总 是 使 用 objects (stk) 来 管理 resources ( 资 
JR) ， 而 且 你 应 该 确保 那些 resource-managing objects (资源 管理 对 象 ) 被 拷贝 时 行为 良 
好 。 在 这 种 情况 下 ， 你 的 assignment operators (赋值 运算 符 ) 在 你 没有 考虑 自 赋 值 的 时 候 可 
能 也 是 self-assignment-safe 〈 自 赋值 安全 ) 的 。 然 而 ， 如 果 你 试图 自己 管理 resources (# 
源 ) (如 果 你 正在 写 一 个 resource-managing class (资源 管理 类 ) ， 你 当然 必须 这 样 做 ) ， 
你 可 能 会 落 入 在 你 用 完 一 个 resource (资源 ) 之 前 就 已 意外 地 将 它 释放 的 陷阱 。 例 如 ， 假 设 
你 创建 了 一 个 class (类 ) ， 它 持 有 一 个 指向 动态 分 配 bitmap (位 图 ) 的 raw pointer ( 裸 指 
针 ) 


class Bitmap { ... }; 
class Widget { 
private: 


Bitmap *pb; // ptr to a heap-allocated object 
}; 


下 面 是 一 个 表面 上 看 似 合 理 operator= 的 实现 ， 但 如 果 出 现 assignment to self (Ama) m 
是 不 安全 的 。 ( 它 也 不 是 exception-safe (异常 安全 ) 的 ， 但 我 们 要 过 一 会 儿 才 会 涉及 到 
它 。) 


Widget& 

Widget: :operator=(const Widget& rhs) // unsafe impl. of operator= 
delete pb; // stop using current bitmap 
pb = new Bitmap(*rhs.pb); // start using a copy of rhs's bitmap 
return *this; // see Item 10 

} 


E E 


ix BA self-assignment ( 自 赋值 ) 问题 在 operator= 的 内 部 ，*this (赋值 的 目标 ) 和 rhs 可 
能 是 同一 个 object 〈 对 象 ) 。 如 果 它 们 是 ， 则 那个 delete 不 仅 会 销毁 current object (当前 对 
R) ÉI bitmap (位 图 ) ， 也 会 销毁 rhs 的 bitmap (位 图 ) 。 在 加 数 的 结尾 ，Widget 一 一 通过 
assignment to self ( 自 赋值 ) 应 该 没有 变化 一 一 发 现 自己 持 有 一 个 指向 已 删除 object (对 
象 ) 的 指针 。 


防止 这 个 错误 的 传统 方法 是 在 operator= 的 开始 处 通过 identity test (一 致 性 检测 ) 来 阻止 
assignment to self ( 自 赋值 ) 


Widget& Widget::operator=(const Widget& rhs) 
{ 
if (this == &rhs) return *this; // identity test: if a self-assignment, 
// do nothing 
delete pb; 
pb = new Bitmap(*rhs.pb); 


return *this; 


这 个 也 能 工作 ， 但 是 我 在 前 面 提 及 那个 operator= 的 早先 版 本 不 仅仅 是 self-assignment- 
unsafe ( 自 赋 值 不 安全 ) 的 ， 它 也 是 exception-unsafe (异常 不 安全 ) 的 ， 而 且 这 个 版 本 还 有 
异常 上 的 麻烦 。 详 细 地 说 ， 如 果 "new Bitmap" 表达 式 引 发 一 个 exception (异常 ) (AREA 
为 供 分 配 的 内 存 不 足 或 者 因为 Bitmap 的 copy constructor ( 找 贝 构造 函数 ) 抛 出 一 个 异 

常 ) , Widget 将 以 持 有 一 个 指向 被 删除 的 Bitmap 的 指针 而 告终 。 这 样 的 指针 是 有 毒 的 ， 你 
不 能 安全 地 删除 它们 。 你 其 至 不 能 安全 地 污 取 它们 。 你 对 它们 唯一 能 做 的 安全 的 事情 大 概 就 
是 花费 大 量 的 调试 精力 来 断定 它们 起 因 于 哪里 。 


幸亏 ， 使 operator= exception-safe (异常 安全 ) 一 般 也 同时 弥补 了 它 的 self-assignment- 
safe (AMAZE) 。 这 就 导致 了 更 加 通用 的 处 理 self-assignment ( 自 赋值 ) 问题 的 方法 就 
是 忽略 它 ， 而 将 焦点 集中 于 达到 exception safety (异常 安全 ) . Item 29 更 加 深入 地 探讨 了 
exception safety (RRR) ， 但 是 在 本 ltem 中 ， 已 经 足以 看 出 ， 在 很 多 情况 下 ， 仔 细 地 调 
整 一 下 语句 的 顺序 就 可 以 得 到 exception-safe (异常 安全 ) (同时 也 是 self-assignment- 
safe (maze) ) 的 代码 。 例 如 ， 在 这 里 ， 我 们 只 要 注意 不 要 删除 pp， 直 到 我 们 拷贝 了 
它 所 指向 的 目标 之 后 : 


Widget& Widget: :operator=(const Widget& rhs) 


Bitmap *pOrig = pb; // remember original pb 
pb = new Bitmap(*rhs.pb); // make pb point to a copy of *pb 
delete pOrig; // delete the original pb 


return *this; 


现在 ， 如 果 "new Bitmap" 抛 出 一 个 exception (异常 ) , pb (以 及 它 所 在 的 Widget) 的 遗迹 
没有 被 改变 。 甚 至 不 需要 identity test (一 致 性 检测 ) ， 这 里 的 代码 也 能 人 处理 assignment to 
self (Bit) ， 因 为 我 们 做 了 一 个 原始 bitmap (位 图 ) 的 拷贝 ， 删 除 原 始 bitmap (位 

A) ， 然 后 指向 我 们 作成 的 拷贝 。 这 可 能 不 是 义理 self-assignment ( 自 赋值 ) 的 最 有 效率 的 
做 法 ， 但 它 能 够 工作 。 


如 果 你 关心 效率 ， 你 可 以 在 函数 开始 处 恢复 identity test (一 致 性 检测 ) 。 然 而 ， 在 这 样 做 之 
前 ， 先 问 一 下 自己 ， 你 认为 self-assignments ( 自 赋值 ) 发 生 的 频率 是 多 少 ， 因 为 这 个 检测 不 
是 免费 午餐 。 它 将 使 代码 〈 源 代码 和 目标 代码 ) 有 少量 增 大 ， 而 且 它 将 在 控制 流 中 引入 一 个 

分 支 ， 这 两 点 都 会 降低 运行 速度 。 例 如 ，instruction prefetching (指令 预 读 ) ，caching (4 

存 ) 和 pipelining 〈 流 水 线 操作 ) 的 效力 都 将 被 降低 。 


另 一 个 可 选 的 手动 排列 operator= 中 语句 顺序 以 确保 实现 是 exception- and self-assignment- 
safe (异常 和 自 赋值 安全 ) 的 方法 是 使 用 被 称 为 "copy and swap" 的 技术 。 这 一 技术 和 
exception safety (异常 安全 ) 关系 密切 ， 所 以 将 在 Item 29 中 描述 。 然 而 ， 这 是 一 个 写 
operator= 的 足够 通用 的 方法 ， 值 得 一 看 ， 这 样 一 个 实现 看 起 来 通常 就 像 下 面 这 样 : 


class Widget { 


void swap(Widget& rhs); // exchange *this's and rhs's data; 
tre // see Item 29 for details 

}; 

Widget& Widget::operator=(const Widget& rhs) 
Widget temp(rhs); // make a copy of rhs's data 
swap(temp); // swap *this's data with the copy's 
return *this; 

} 


在 这 个 主题 上 的 一 个 变种 利用 了 如 下 事实 : (1) 一 个 clsaa (类 ) 的 copy assignment (44 
贝 赋值 运算 符 ) 可 以 被 声明 为 take its argument by value (以 传 值 方 式 取得 它 的 参数 ) ; 
(2) 通过 传 值 方式 传递 某 些 东西 以 做 出 它 的 一 个 copy (n) (参见 Item 20) 


Widget& Widget: :operator=(Widget rhs) // rhs is a copy of the object 
{ // passed in — note pass by val 


swap(rhs); // swap *this's data with 
// the copy's 
return *this; 


} 


对 我 个 人 来 说 ， 我 担心 这 个 方法 在 灵活 的 祭坛 上 御 牲 了 清晰 度 ， 但 是 通过 将 拷贝 操作 从 画 数 
体 中 转移 到 参数 的 构造 中 ， 有 时 能 使 编译 器 产生 更 有 效率 的 代码 倒 也 是 事实 。 


Things to Remember 
e 4— object (GR) 被 赋值 给 自己 的 时 候 ， 确 保 operator= 是 行为 良好 的 。 技 巧 包括 比 


较 source ( 源 ) 和 target objects (目标 对 象 ) 的 地 址 ， 关 注 语 句 顺序 ， 和 copy-and- 
swap。 


。 如 果 两 个 或 更 多 objects 对象) 相同， 确保 任何 操作 多 于 一 个 object (对 象 ) 的 函数 行 
为 正确 。 


Item 12: 拷贝 一 个 对 象 的 所 有 组 成 部 分 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


在 设计 良好 的 面向 对 象 系统 中 ， 封 装 了 对 象 内 部 的 配件 ， 仅 留 两 个 画 数 用 于 对 象 的 拷贝 : 一 
般 称 为 拷贝 构造 画 数 (copy constructor) 和 拷贝 赋值 运算 符 (copy assignment operator) 。 
我 们 将 它们 统称 为 拷贝 函数 (copying functions) 。ltem 5 讲述 了 如 果 需 要 ， 编 译 器 会 生成 拷 
贝 函 数 ， 而 且 阐 明了 编译 器 生成 的 版 本 正 象 你 所 期 望 的 : 它们 拷贝 被 拷贝 对 象 的 全 部 数据 。 


当 你 声明 了 你 自己 的 拷贝 函数 ， 你 就 是 在 告诉 编译 器 你 不 喜欢 缺 省 实现 中 的 某 些 东 西 。 编 译 
器 对 此 好 像 怒 发 冲 冠 ， 而 且 它 们 会 用 一 种 古怪 的 方式 报复 : 当 你 的 实现 存在 一 些 几 乎 可 以 确 
定 错 误 时 ， 它 偏偏 不 告诉 你 。 

考虑 一 个 象征 消费 者 (customers) 的 类 ， 这 里 的 拷贝 豆 数 是 手写 的 ， 以 便 业 对 它们 的 调用 记 
AB : 


void logCall(const std::string& funcName); // make a log entry 


class Customer { 
public: 


Customer(const Customer& rhs); 


Customer& operator=(const Customer& rhs); 


private: 
std::string name; 
J; 
Customer : :Customer (const Customer& rhs) 
: name(rhs.name) // copy rhs's data 


logCall("Customer copy constructor"); 


Customer& Customer: :operator=(const Customer& rhs) 
logCall("Customer copy assignment operator"); 
name = rhs.name; // copy rhs's data 


return *this; // see Item 10 


} 


直到 Customer 中 加 入 了 另外 的 数据 成 





这 里 的 每 一 件 事 看 起 来 都 不 错 ， 实 际 上 也 确实 不 错 
员 


class Date { ... }; // for dates in time 
class Customer { 
public: 

mei // as before 
private: 

std::string name; 

Date lastTransaction; 


}; 


在 这 里 ， 已 有 的 拷贝 函数 只 进行 了 部 分 拷贝 : 它们 拷贝 了 Customer 的 name， 但 没有 拷贝 它 
的 lastTransaction。 然 而 ， 大 部 分 编译 器 对 此 窜 不 在 意 ， 即 使 是 在 最 高 的 警告 级 别 (maximal 
warning level) (参见 Item 53) 。 这 是 它们 在 对 你 写 自 己 的 拷贝 函数 进行 报复 。 你 拒绝 了 它 
们 写 的 拷贝 函数 ， 所 以 如 果 你 的 代码 是 不 完善 的 ， 他 们 也 不 告诉 你 。 结 论 显 而 易 见 : 如 果 你 
为 一 个 类 增加 了 一 个 数据 成 员 ， 你 务必 要 做 到 更 新 拷贝 西数 。 (你 还 需要 更 新 类 中 的 全 部 的 
ERA (参见 Item 4 和 45) 以 及 任何 非 标准 形式 的 operator= (Item 10 给 出 了 一 个 例 
F) 。 如 果 你 忘记 了 ， 编 译 器 未 必 会 提醒 你 。) 
这 个 问题 最 为 迷惑 人 的 情形 之 一 是 它 会 通过 继承 发 生 。 考 虑 : 
class PriorityCustomer: public Customer { // a derived class 
public: 
priorityCustomer (const PriorityCustomer& rhs); 
PriorityCustomer& operator=(const PriorityCustomer& rhs); 
private: a 
int priority; 


PriorityCustomer::PriorityCustomer(const PriorityCustomer& rhs) 
: priority(rhs.priority) 


logCall("PriorityCustomer copy constructor"); 
PriorityCustomer& 
PriorityCustomer::operator=(const PriorityCustomer& rhs) 
logCall("PriorityCustomer copy assignment operator"); 
priority = rhs.priority; 


return *this; 


PriorityCustomer 的 拷贝 函数 看 上 去 好 像 拷贝 了 PriorityCustomer 中 的 每 一 样 东 西 ， 但 是 再 看 
一 下 。 是 的 ， 它 确实 拷贝 了 PriorityCustomer 声明 的 数据 成 员 ， 但 是 每 个 PriorityCustomer 
还 包括 一 份 它 从 Customer 继承 来 的 数据 成 员 的 副本 ， 而 那些 数据 成 员 根本 没有 被 拷贝 ! 
PriorityCustomer 的 拷贝 构造 画 数 没有 指定 传递 给 它 的 基 类 构造 辑 数 的 参数 (也 就 是 说 ， 在 它 
的 成 员 初 始 化 列表 中 没有 提 及 Customer) ， 所 以 ，PriorityCustomer 对 象 的 Customer 部 分 


被 Customer MWS HAETCERAYI N Reet -使 用 缺 省 构造 画 数 。 (假设 它 有 ， 如 果 
没有 ， 代 码 将 无 法 编译 。) 那个 构造 函数 为 name 和 lastTransaction 进行 一 次 缺 省 的 初始 
化 。 


对 于 PriorityCustomer 的 拷贝 赋值 运算 符 ， 情 况 有 些微 的 不 同 。 它 不 会 试图 用 任何 方法 改变 
它 的 基 类 的 数据 成 员 ， 所 以 它们 将 保持 不 变 。 


无 论 何 时 ， 你 打算 自己 为 一 个 派生 类 写 丘 贝 函 数 时 ， 你 必须 注意 同时 拷贝 基 类 部 分 。 那 些 地 
方 的 典型 特征 当然 是 private (参见 Item 22) ， 所 以 你 不 能 直接 访问 它们 。 派 生 类 的 拷贝 函数 
必须 调用 和 它们 对 应 的 基 类 辑 数 : 


PriorityCustomer::PriorityCustomer(const PriorityCustomer& rhs) 
Customer(rhs), // invoke base class copy ctor 
priority(rhs.priority) 


logCall("PriorityCustomer copy constructor"); 


PriorityCustomer& 
PriorityCustomer::operator=(const PriorityCustomer& rhs) 


logCall("PriorityCustomer copy assignment operator"); 


Customer: :operator=(rhs); // assign base class parts 
priority = rhs.priority; 


return *this; 


A ltem 标题 中 的 "copy all parts" 的 含义 现在 应 该 清楚 了 。 当 你 写 一 个 拷贝 函数 ， 需 要 保证 
(1) 拷贝 所 有 本 地 数据 成 员 以 及 (2) 调用 所 有 基 类 中 的 适当 的 拷贝 函数 。 


在 实际 中 ， 两 个 拷贝 汞 数 经 常 有 相似 的 画 数 体 ， 而 这 一 点 可 能 吸引 你 试图 通过 用 一 个 汞 数 调 
用 另 一 个 来 避免 代码 重复 。 你 希望 避免 代码 重复 的 想法 值得 肯定 ， 但 是 用 一 个 拷贝 本 数 调用 
另 一 个 来 做 到 这 一 点 是 错误 的 。 


用 拷贝 赋值 运算 符 调用 拷贝 构造 函数 是 没有 意义 的 ， 因 为 你 这 桩 做 就 是 试图 去 构造 一 个 已 经 
存在 的 对 象 。 这 太 荒 雇 了 ， 甚 至 没有 一 种 语法 来 支持 它 。 有 一 种 语法 看 起 来 好 像 能 让 你 这 样 
做 ， 但 实际 上 你 做 不 到 ， 还 有 一 种 语法 采用 迁 回 的 方法 这 样 做 ， 但 它们 在 某 种 条 件 下 会 对 破 
坏 你 的 对 象 。 所 以 我 不 打算 给 你 看 任何 那样 的 语法 。 无 条 件 地 接受 这 个 观点 : 不 要 用 拷贝 赋 
值 运 算 符 调用 拷贝 构造 图 数 。 





党 试 一 下 另 一 种 相反 的 方法 一 一 用 拷贝 构造 本 数 调用 拷贝 赋值 运算 符 一 一 这 同样 是 荒 廖 的 。 
一 个 构造 本 数 初始 化 新 的 对 象 ， 而 一 个 赋值 运算 符 只 能 用 于 已 经 初始 化 过 的 对 象 。 借 助 构造 
过 程 给 一 个 对 象 赋值 将 意味 着 对 一 个 尚未 初始 化 的 对 象 做 一 些 事 ， 而 这 些 事 只 有 用 于 已 初始 
化 对 象 寺 有 意义 。 简 直 是 胡 搞 ! 不 要 做 这 种 尝试 。 


作为 一 种 代替 ， 如 果 你 发 现 你 的 拷贝 构造 画 数 和 拷贝 赋值 运算 符 有 相似 的 代码 ， 通 过 创建 第 
三 个 供 两 者 调用 的 成 员 函 数 来 消除 重复 。 这 样 的 范 数 当然 是 private 的 ， 而 且 经 常 叫做 inite 
这 一 策略 是 在 拷贝 构造 画 数 和 拷贝 赋值 运算 符 中 消除 代码 重复 的 安全 的 ， 被 证 实 过 的 方法 。 


Things to Remember 
。 拷贝 函数 应 该 保证 拷贝 一 个 对 象 的 所 有 数据 成 员 以 及 所 有 的 基 类 部 分 。 


。 不 要 试图 依据 一 个 拷贝 琅 数 实现 另 一 个 。 作 为 代替 ， 将 通用 功能 放 入 第 三 个 供 双 方 调用 
的 函数 。 


Item 13: 使 用 对 象 管理 资源 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


假设 我 们 和 一 个 投资 (ND, RE, ASS) 模型 库 一 起 工作 ， 各 种 各 样 的 投资 形式 从 一 个 
根 类 Investment 派生 出 来 : 


class Investment { ... }; // root class of hierarchy of 
// investment types 


进一步 假设 这 个 库 使 用 了 通过 一 个 factory HA (参见 Item 7) 为 我 们 提供 特定 Investment 
对 象 的 方法 : 


Investment* createInvestment(); // return ptr to dynamically allocated 
// object in the Investment hierarchy; 
// the caller must delete it 
// (parameters omitted for simplicity) 


通过 注释 指出 ， 当 createlnvestment HORER RAB HAR, A createlnvestment 的 调 
用 者 负责 删除 它 。 那 么 ， 请 考虑 ， 写 一 个 函数 f 来 履行 以 下 职责 : 


void f() 

{ 
Investment *pInv = createInvestment(); // call factory function 
eat // use pInv 
delete pInv; // release object 

} 


这 个 看 上 去 没 问题 ， 但 是 有 几 种 情形 会 造成 f 在 删除 它 从 createlnvestment 得 到 的 
investment 对 象 时 失败 。 有 可 能 在 这 个 函数 的 "…" 部 分 的 某 处 有 一 个 提前 出 现 的 return 语 
句 。 如 果 这 样 一 个 return 执行 了 ， 控 制 流 程 就 再 也 无 法 到 达 delete 语句 。 还 可 能 发 生 的 一 个 
类 似 情况 是 如 果 createlnvestment 的 使 用 和 删除 在 一 个 循环 里 ， 而 这 个 循环 以 一 个 continue 
或 goto 语句 提前 退出 。 还 有 ，"…" 中 的 一 些 语 句 可 能 抛 出 一 个 异常 。 如 果 这 样 ， 控 制 流 程 不 
会 再 到 达 那 个 delete。 无 论 那个 delete 被 如 何 跳 过 ， 我 们 泄漏 的 不 仅仅 是 容纳 investment 对 
象 的 内 存 ， 还 包括 那个 对 象 持 有 的 任何 资源 。 


当然 ， 小 心 递 愤 地 编程 能 防止 这 各 种 错误 ， 但 考虑 到 这 些 代码 可 能 会 随 着 时 间 的 流逝 而 发 生 
变化 。 为 了 对 软件 进行 维护 ， 一 些 人 可 能 会 在 没有 完全 把 握 对 这 个 函数 的 资源 管理 策略 的 其 
它 部 分 的 影响 的 情况 下 增加 一 个 return 或 continue 240), LEEK, fH"..." 部 分 可 能 调用 


T-APA FWE RRIKA, (EECRMR RRAR EAST. Kem f 总 能 到 达 它 的 
delete 语句 根本 靠不住 。 


为 了 确保 createlnvestment 返回 的 资源 总 能 被 释放 ， 我 们 需要 将 那些 资源 放 和 人 一 个 类 中 ， 这 
个 类 的 析 构 范 数 在 控制 流程 离开 ff 的 时 候 会 自动 释放 资源 。 实 际 上 ， 这 只 是 本 ltem 介绍 的 观 
念 的 一 半 : 将 资源 放 到 一 个 对 象 的 内 部 ， 我 们 可 以 依赖 C++ 的 自动 地 调用 析 构 函数 来 确保 资 
源 被 释放 。 (过 一 会 儿 我 们 还 要 介绍 本 Item 观念 的 另 一 半 。) 


许多 资源 都 是 动态 分 配 到 堆 上 的 ， 并 在 一 个 单独 的 块 或 函数 内 使 用 ， 而 且 应 该 在 控制 流程 离 
开 那 个 块 或 画 数 的 时 候 释 放 。 标 准 库 的 auto_ptr 正 是 为 这 种 情形 量体裁衣 的 。auto_ptr 是 一 
个 类 似 指 针 的 对 象 (一 个 智能 指针 ) ， 它 的 析 构 函数 自动 在 它 指向 的 东西 上 调用 deletes F 
面 就 是 如 何 使 用 auto_ptr 来 预防 f 的 潜在 的 资源 泄漏 : 


void f() 


std::auto_ptr<Investment> pInv(createInvestment()); // call factory 
// function 
// use pInv as 
// before 
} // automatically 
// delete pInv via 
// auto_ptr's dtor 


这 个 简单 的 例子 示范 了 使 用 对 象 管理 资源 的 两 个 重要 的 方面 : 


。 获得 资源 后 应 该 立即 移交 给 资源 管理 对 象 。 如 上 ，createlnvestment 返回 的 资源 被 用 来 
初始 化 即将 用 来 管理 它 的 auto_ptr。 实 际 上 ， 因 为 获取 一 个 资源 并 在 同一 个 语句 中 初始 
化 资源 管理 对 象 是 如 此 常见 ， 所 以 使 用 对 象 管理 资源 的 观念 也 常常 被 称 为 Resource 
Acquisition Is Initialization (RAIN)。 有 时 被 获取 的 资源 是 被 赋值 给 资源 管理 对 象 的 ， 而 不 
是 初始 化 它们 ， 但 这 两 种 方法 都 是 在 获取 资源 的 同时 就 立即 将 它 移交 给 资源 管理 对 象 。 


资源 管理 对 象 使 用 它们 的 析 构 函数 确保 资源 被 释放 。 因 为 当 一 个 对 象 被 销毁 时 (例如 ， 
当 一 个 对 象 离开 其 活动 范围 ) 会 自动 调用 析 构 函数 ， 无 论 控制 流程 是 怎样 离开 一 个 块 
的 ， 资 源 都 会 被 正确 释放 。 如 果 释 放 资 源 的 动作 会 引起 异常 抛 出 ， 事 情 就 会 变 得 赫 手 ， 
不 过 ， 关 于 那些 问题 请 访问 ltem 8， 所 以 我 们 不 必 担 心 它 。 


因为 当 一 个 auto_ptr 被 销毁 的 时 候 ， 会 自动 删除 它 所 指向 的 东西 ， 所 以 不 要 让 超过 一 个 的 
auto_ptr 指向 同一 个 对 象 非 常 重要 。 如 果 发 生 了 这 种 事情 ， 那 个 对 象 就 会 被 删除 超过 一 次 ， 
而 且 会 让 你 的 程序 通过 捷径 进入 未 定义 行为 。 为 了 防止 这 个 问题 ，auto_ptrs 具有 不 同 寻 常 的 
特性 : 拷贝 它们 〈 通 过 拷贝 构造 画 数 或 者 拷贝 赋值 运算 符 ) 就 是 将 它们 置 为 空 ， 持 贝 的 指针 
被 设想 为 资源 的 唯一 所 有 权 。 


sstd: :auto_ptr<Investment> // pInvi points to the 
pInvi(createInvestment()); // object returned from 
// createInvestment 


std::auto_ptr<Investment> pInv2(pInvi1i); // pInv2 now points to the 
// object; pInvi is now null 


pInvi = pInv2; // now pInvi points to the 
// object, and pInv2 is null 


这 个 奇怪 的 拷贝 行为 ， 增 加 了 潜在 的 需求 ， 就 是 通过 auto_ptr 管理 的 资源 必须 绝对 没有 超过 
一 个 auto_ptr 指向 它们 ， 这 也 就 意味 着 auto_ptrs 不 是 管理 所 有 动态 分 配 资源 的 最 好 方法 。 
例如 ，STL 容器 要 求 其 内 含 物 能 表现 出 “正常 的 "拷贝 行为 ， 所 以 auto_ptrs 的 容器 是 不 被 允许 
的 。 


相对 于 auto_ptrs， 另 一 个 可 选 方案 是 一 个 引用 计数 智能 指针 (reference-counting smart 
pointer, RCSP) 。 一 个 RCSP 是 一 个 智能 指针 ， 它 能 持续 跟踪 有 多 少 对 象 指 向 一 个 特定 的 资 
源 ， 并 能 够 在 不 再 有 任何 东西 指向 那个 资源 的 时 候 删 除 它 。 就 这 一 点 而 论 ，RCSP 提供 的 行 
为 类 似 于 垃圾 收集 (garbage collection) 。 与 垃圾 收集 不 同 的 是 ， 无 论 如 何 ，RCSP 不 能 打 
破 循环 引用 (例如 ， 两 个 没有 其 它 使 用 者 的 对 象 互 相 指 向 对 方 ) 。 


TR1 BY tr1::shared_ptr (参见 Item 54) 是 一 个 RCSP， 所 以 你 可 以 这 样 写 f: 


void f() 
{ 


std::tri::shared_ptr<Investment> 
pInv(createInvestment()); // call factory function 
ate // use pInv as before 
} // automatically delete 
// pInv via shared_ptr's dtor 


这 里 的 代码 看 上 去 和 使 用 auto_ptr 的 几乎 相同 ， 但 是 拷贝 shared_ptrs 的 行为 却 自然 得 多 : 


void f() 
std::tri::shared_ptr<Investment> // pInvi points to the 
pInvi(createInvestment()); // object returned from 
// createInvestment 
std::tri::shared_ptr<Investment> // both 
pInvi and pInv2 now 
pInv2(pInv1); // point to the object 
pInvi = pInv2; // ditto — nothing has 
// changed 
} // pInvi and pInv2 are 


// destroyed, and the 
// object they point to is 
// automatically deleted 


因为 拷贝 tr1::shared_ptrs 的 工作 “符合 预期 ”， 它 们 能 被 用 于 STL 容器 以 及 其 它 和 auto_ptr 的 
非 正 统 的 拷贝 行为 不 相 容 的 环境 中 。 


不 要 搞 错 ， 本 ltem 不 是 关于 auto_ptr, tri::shared_pt 或 任何 其 它 种 类 的 智能 指针 。 而 是 关 
于 使 用 对 象 管理 资源 的 重要 性 的 。auto_ptr 和 tr1::shared_ptr 仅仅 是 做 这 些 事 的 对 象 的 例 
F. (关于 tr1::shared_ptr 的 更 多 信息 ， 请 参考 ltem 14，18 和 54。) 


auto_ptr 和 tr1::shared_ptr 都 在 它们 的 析 构 本 数 中 使 用 delete， 而 不 是 delete []。 (Item 16 
描述 两 者 的 差异 。) 这 就 意味 着 将 auto_ptr 或 tr1::shared pt 用 于 动态 分 配 的 数组 是 个 馈 主 
意 ， 可 是 ， 可 悲 的 是 ， 那 居然 可 以 编译 : 


std::auto_ptr<std::string> // bad idea! the wrong 
aps(new std::string[10]); // delete form will be used 
std::tri::shared_ptr<int> spi(new int[1024]); // same problem 


你 可 能 会 吃惊 地 发 现 C++ 中 没有 可 用 于 动态 分 配 数组 的 类 似 auto_ptr 3 tr1::shared_ptr 这 样 
的 东西 ， 甚 至 在 TR1 中 也 没有 。 那 是 因为 vector 和 string 几乎 总 是 能 代替 动态 分 配 数组 。 如 
果 你 依然 觉得 有 可 用 于 数组 的 类 似 auto_ptr 和 类 似 tr1::shared_ptr 的 类 更 好 一 些 的 话 ， 可 以 
KAZ Boost (参见 Item 55) 。 在 那里 ， 你 将 高 兴 地 找到 boost::scoped_array 和 
boost::shared_array 两 个 类 提供 你 在 寻找 的 行为 。 


本 ltem 的 关于 使 用 对 象 管理 资源 的 指导 间接 表明 : 如 果 你 手动 释放 资源 (例如 ， 使 用 
delete， 而 不 使 用 资源 管理 类 ) ， 你 就 是 在 自 找 麻烦 。 像 auto_ptr 和 tr1::shared_ptr 这 样 的 
预制 的 资源 管理 类 通常 会 使 本 ltem 的 建议 变 得 容易 ， 但 有 时 ， 你 使 用 了 一 个 资源 ， 而 这 些 预 
加 工 的 类 不 能 如 你 所 愿 地 做 事 。 如 果 碰 上 这 种 情况 ， 你 就 需要 精心 打造 你 自己 的 资源 管理 
类 。 那 也 并 非 困难 得 可 怕 ， 但 它 包 含 一 些 需要 你 细心 考虑 的 微妙 之 处 。 那 些 需 要 考虑 的 事项 
是 Item 14 和 15 的 主题 。 


作为 最 后 的 意见 ， 我 必须 指出 createlnvestment 的 裸 指针 (raw pointer) 的 返回 形式 就 是 资 
源 泄漏 的 请 帖 ， 因 为 调用 者 忘记 在 他 们 取 回 来 的 指针 上 调用 delete 实在 是 太 容易 了 。 (即使 
他 们 使 用 一 个 auto_ptr 3 tr1::shared_ptr 来 完成 delete， 他 们 仍然 必须 记 住 籽 
createlnvestment 的 返回 值 存储 到 智能 指针 对 象 中 。) 对 付 这 个 问题 需要 改变 
createlnvestment 的 接口 ， 这 是 我 在 Item 18 中 安排 的 主题 。 


Things to Remember 


。 为 了 防止 资源 泄漏 ， 使 用 RAI 对 象 ， 在 RAII 对 象 的 构造 画 数 中 获得 资源 并 在 析 构 函数 
中 释放 它们 。 


。 两 个 通用 的 RAII tr1::shared_ptr 和 auto_ptr. tr1::shared_ptr 通常 是 更 好 的 选择 ， 
为 它 的 拷贝 时 的 行为 是 符合 直 沉 的。 拷贝 一 个 auto ptr 是 将 它 置 为 空 。 


Item 14: ZIS4 E A REHE X NE N íT 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


Item 13 介绍 了 作为 资源 管理 类 支柱 的 Resource Acquisition Is Initialization (RAII) 原则 ， 并 
描述 了 auto_ptr 和 tr1::shared_ptr 在 基于 堆 的 资源 上 运用 这 一 原则 的 表现 。 然 而 ， 并 非 所 有 
的 资源 都 是 基于 堆 的 ， 对 于 这 样 的 资源 ， 像 auto_ptr 和 tr1::shared_ptr 这 样 的 智能 指针 通常 
就 不 像 resource handlers (资源 管理 者 ) 那样 合适 。 在 这 种 情况 下 ， 有 时 ， 你 可 能 要 根据 你 
自己 的 需要 去 创建 你 自己 的 资源 管理 类 。 


例如 ， 假 设 你 使 用 C API 提供 的 lock 和 unlock 函数 去 操纵 Mutex 类 型 的 互 斥 体 对 象 : 


void lock(Mutex *pm); // lock mutex pointed to by pm 


void unlock(Mutex *pm); // unlock the mutex 


为 了 确保 你 从 不 会 忘记 解锁 一 个 被 你 加 了 锁 的 Mutex， 你 希望 创建 一 个 类 来 管理 锁 。 RAR 
则 规定 了 这 样 一 个 类 的 基本 结构 ， 通 过 构造 画 数 获取 资源 并 通 ae (MAME : 


class Lock { 
public: 
explicit Lock(Mutex *pm) 
: mutexPtr(pm) 
{ lock(mutexPtr); } // acquire resource 


~Lock() { unlock(mutexPtr); } // release resource 
private: 


Mutex *mutexPtr; 


}; 


客户 按照 RAII 风格 的 惯例 来 使 用 Lock : 


Mutex m; // define the mutex you need to use 
// create block to define critical section 
Lock ml(&m); // lock the mutex 
ri // perform critical section operations 


} // automatically unlock mutex at end 
// of block 


这 没什么 问题 ， 但 是 如 果 一 个 Lock 对 象 被 拷贝 应 该 发 生 什么 ? 


Lock ml1(&m); // lock m 


Lock ml2(m11); // copy ml1 to ml2-what should 
// happen here? 


这 是 一 个 更 一 般 问 题 的 特定 实例 ， 每 一 个 RAII 类 的 作者 都 要 面临 这 样 的 问题 : 当 一 个 RAII 
对 象 被 拷贝 的 时 候 应 该 发 生 什么 ?3 大 多 数 情 况 下 ， 你 可 以 从 下 面 各 种 可 能 性 中 挑选 一 个 : 


。 禁止 拷贝 。 在 很 多 情况 下 ， 人 允许 RAI 被 拷贝 是 没有 意义 的 。 这 对 于 像 Lock 这 样 类 很 可 
能 是 正确 的 ， 因 为 同步 的 基本 要 素 的 "副本 ”很 少 有 什么 意义 。 当 拷贝 对 一 个 RAII 类 没有 
什么 意义 的 时 候 ， 你 应 该 禁止 它 。ltem 6 解释 了 如 何 做 到 这 一 点 。 声 明 拷贝 操作 为 私 
有 。 对 于 Lock， 看 起 来 也 许 像 这 样 : 


class Lock: private Uncopyable { // prohibit copying — see 
public: // Item 6 

aie // as before 

3; 


。 对 底层 的 资源 引用 计数 。 有 时 人 们 需要 的 是 保持 一 个 资源 直到 最 后 一 个 使 用 它 的 对 象 被 
销毁 。 在 这 种 情况 下 ， 拷 由 一 个 RAII 对 象 应 该 增加 引用 这 一 资源 的 对 象 的 数目 。 这 也 就 
是 使 用 tr1::shared_ptr 时 “拷贝 "的 含意 。 


通常 ，RAII 类 只 需要 包含 一 个 tr1::shared_ptr 数据 成 员 就 能 够 实现 引用 计数 的 拷贝 行 
为 。 例 如 ， 如 果 Lock 要 使 用 引用 计数 ， 他 可 能 要 将 mutexPtr 的 类 型 从 Mutex* 改变 为 
tr1::shared_ptr<Mutex>。 不 幸 的 是 ，tr1::shared_ptr 的 缺 省 行为 是 当 它 所 指向 的 未 西 的 
引用 计数 变 为 0 的 时 候 将 它 删除 ， 但 这 不 是 我 们 要 的 。 当 我 们 使 用 Mutex 完毕 后 ， 我 们 
想 要 将 它 解 锁 ， 而 不 是 将 它 删 除 。 


幸运 的 是 ，tr1::shared_ptr 允许 一 个 "deleter" 规范 当 引 用 计数 变 为 0 时 调用 的 一 个 
函数 或 者 函数 对 象 。 (这 一 功能 是 auto_ptr 所 没有 的 ，auto_ptr 总 是 删除 它 的 指针 。 ) 
deleter 是 tr1::shared_ptr 的 构造 本 数 的 可 选 的 第 二 个 参数 ， 所 以 ， 代 码 看 起 来 就 像 这 
样 : 





class Lock { 


public: 
explicit Lock(Mutex *pm) // init shared_ptr with the Mutex 
: mutexPtr(pm, unlock) // to point to and the unlock func 
// as the deleter 
lock(mutexPtr.get()); // see Item 15 for info on "get" 
private: 
std::tri::shared_ptr<Mutex> mutexPtr; // use shared_ptr 


在 这 个 例子 中 ， 注 意 Lock 类 是 如 何不 再 声明 一 个 析 构 函数 的 。 那 是 因为 它 不 再 需要 。 
ltem 5 解释 了 一 个 类 的 析 构 函数 (无 论 它 是 编译 器 生成 还 是 用 户 定 义 ) 会 自动 调用 这 个 
类 的 非 静态 (non-static) 数据 成 员 的 析 构 画 数 。 在 本 例 中 ， 就 是 mutexPtr。 但 是 ， 当 互 


斥 体 的 引用 计数 变 为 0 时 ，mutexPtr I ARAS A aAA tr1::shared_ptr 的 
deleter 一 一 在 此 就 是 unlock。 (看 过 这 个 类 的 源 代码 的 人 多 半 意 识 到 需要 增加 一 条 注释 
表明 你 并 非 忘 记 了 析 构 ， 而 只 是 依赖 编译 器 生成 的 缺 省 行为 。) 


拷贝 底层 的 资源 。 有 时 就 像 你 所 希望 的 你 可 以 拥有 一 个 资源 的 多 个 副本 ， 唯 一 的 前 提 是 
你 需要 一 个 资源 管理 关 确 保 当 你 使 用 完 它 之 后 ， 每 一 副本 都 会 被 释放 。 在 这 种 情况 下 ， 
拷贝 一 个 资源 管理 对 象 也 要 同时 拷贝 被 它 余 藏 的 资源 。 也 就 是 说 ， 找 贝 一 个 资源 管理 类 
需要 完成 一 次 "深层 拷贝" 


某 些 标准 string 类 型 的 实现 是 由 堆 内 存 的 指针 组 成 ， 挫 内 存 中 存储 着 组 成 那个 string 的 
字符 。 这 样 的 字符 串 对 象 包含 指向 堆 内 存 的 指针 。 当 一 个 string 对 象 被 拷贝 ， 这 个 副本 
应 该 由 那个 指针 和 它 所 指向 的 内 存 组 成 。 这 样 的 strings 表现 为 深层 拷贝 。 
e。 传递 底层 资源 的 所 有 权 。 在 某 些 特殊 场合 ， 你 可 能 希望 确保 只 有 一 个 RAII 对 象 引 用 一 个 

裸 资源 (raw resource) ， 而 当 这 个 RAI 对 象 被 拷贝 的 时 候 ， 资 源 的 所 有 权 从 被 拷贝 的 
对 象 传递 到 拷贝 对 象 。 就 像 Item 13 所 说 明 的 ， 这 就 是 使 用 auto_ptr 时 “拷贝 "的 合意 。 
拷贝 函数 (copying functions) (拷贝 构造 琅 数 和 拷贝 赋值 运算 符 ) 可 能 是 由 编译 器 生成 
的 ， 所 以 除非 编译 器 生成 的 版 本 所 做 的 事 正 是 你 所 要 的 (ltem 5 说 明了 这 些 缺 省 行 
为 ) ， 你 应 该 自己 编写 它们 。 在 某 些 情况 下 ， 你 也 要 支持 这 些 函 数 的 泛 型 化 版 本 。 这 样 
的 版 本 在 Item 45 描述 。 

Things to Remember 

拷贝 一 个 RAII 对 象 必须 拷贝 它 所 管理 的 资源 ， 所 以 资源 的 拷贝 行为 决定 了 RAII 对 象 的 拷贝 

行为 。 


普通 的 RAI 类 的 拷贝 行为 不 接受 拷贝 和 进行 引用 计数 ， 但 是 其 它 行为 是 有 可 能 的 。 


Item 15: 在 资源 管理 类 中 准备 访问 梨 资 源 (raw 
resources) 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


资源 管理 类 真是 太 棒 了 。 他 们 是 你 防御 资源 泄漏 的 防波堤 ， 没 有 这 样 的 泄漏 是 设计 和 良好 的 系 
统 的 基本 特征 。 在 一 个 完美 的 世界 中 ， 你 可 以 在 所 有 与 资源 的 交互 中 依赖 这 样 的 类 ， 从 来 不 
需要 因为 直接 访问 裸 资 源 (raw resources) 而 天 污 你 的 手 。 但 是 这 个 世界 并 不 完美 ， 很 多 
API 直接 涉及 资源 ， 所 以 除非 你 计划 坚决 放弃 使 用 这 样 的 AP] (这 种 事 很 少 会 成 为 实际 ) , B 
则 ， 你 就 要 经 常 绕 过 资源 管理 类 而 直接 处 理 裸 资源 (raw resources) 。 


例如 ，ltem 13 介绍 的 使 用 类 似 auto_ptr 5X tr1::shared_ptr 这 样 的 智能 指针 来 持 有 调用 类 似 
createlnvestment 这 样 的 factory NAAN ER : 


std::tri::shared ptr&lt;Investment&gt; pInv(createInvestment()); // from Item 13 


假设 你 打算 使 用 的 一 个 与 Investment RETHA E HEB : 


int daysHeld(const Investment *pi); // return number of days 
// investment has been held 


你 打算 像 这 样 调用 它 ， 


int days = daysHeld(pInv); // error! 


但 是 这 代码 不 能 编译 : daysHeld 要 求 一 个 裸 的 Investment* 指针 ， 但 是 你 传 给 它 一 个 类 型 为 
tr1::shared_ptr<Investment> 的 对 象 。 

你 需要 一 个 将 RAII 类 (当前 情况 下 是 tr1::shared_ptr) 的 对 象 转化 为 它 所 包含 的 裸 资源 ( 例 
A, REKI Investment*) 的 方法 。 有 两 个 常规 方法 来 做 这 件 事 。 显 式 转 换 和 隐 式 转换 。 


tr1::shared_ptr 和 auto_ptr 都 提供 一 个 get 成 员 画 数 进行 显示 转换 ， 也 就 是 说 ， 返 回 一 个 智 
能 指针 对 象 内 部 的 裸 指 针 (raw pointer) (或 它 的 一 个 副本 ) 


int days = daysHeld(pInv.get()); // fine, passes the raw pointer 
// in pInv to daysHeld 


就 像 实 际 上 的 所 有 智能 指针 类 一 样 ，tr1::shared_ptr 和 auto_ptr 也 都 重 载 了 指针 解 引 用 操作 


符 (pointer dereferencing operators) 
到 底层 的 和 裸 指 针 (raw pointers) 


class Investment { 
public: 
bool isTaxFree() const; 


3; 
Investment* createInvestment(); 


std::tri::shared_ptr<Investment> 
pii(createInvestment()); 


bool taxable1 = !(pii->isTaxFree()); 


(operator-> 和 operator*) ， 而 这 样 就 允许 隐 式 转换 


// root class for a hierarchy 
// of investment types 


// factory function 


// have tri::shared_ptr 
// manage a resource 


// access resource 
// via operator-> 


std::auto_ptr<Investment> pi2(createInvestment()); // have auto_ptr 


bool taxable2 = !((*pi2).isTaxFree()); 


为 有 些 时 候 有 必要 取得 RAI 对 象 内 部 的 裸 资源 ， 


// manage a 
// resource 


// access resource 
// via operator* 


所 以 一 些 RAI 类 的 设计 者 就 通过 提供 一 


个 隐 式 转换 画 数 来 给 刹车 抹 油 。 例 如 ， 考 虑 以 下 这 个 RAII 类 ， 它 要 为 C API 提供 原始 状态 区 


字体 资源 : 
FontHandle getFont(); 


void releaseFont(FontHandle fh); 
class Font { 


public: 
explicit Font(FontHandle fh) 
: f(fh) 
{} 
~Font() { releaseFont(f); } 
private: 
FontHandle f; 
}; 


// 
// 


// 
// 


// 
// 
// 


// 


// 


from C API—params omitted 
for simplicity 


from the same C API 
RAII class 


acquire resource; 
use pass-by-value, because the 
C API does 


release resource 


the raw font resource 


假设 有 一 个 巨大 的 与 字体 有 关 的 C API 只 能 与 FontHandle 打交道 ， 这 就 需要 频繁 地 将 Font 
对 象 转 换 为 FontHandle。Font 类 可 以 提供 一 个 显 式 的 转换 函数 ， 比 如 get: 


class Font { 
public: 


FontHandle get() const { return f; } 


}; 


// 


explicit conversion function 


不 幸 的 是 ， 这 就 要 求 客户 每 次 与 API 通信 时 都 要 调用 get : 


void changeFontSize(FontHandle f, int newSize); // from the C API 
Font f(getFont()); 


int newFontSize; 


changeFontSize(f.get(), newFontSize); // explicitly convert 
// Font to FontHandle 


一 些 程 序 员 可 能 发 现 对 显 式 请 求 这 个 转换 的 需求 足以 全 人 郁 头 而 避免 使 用 这 。 反 过 来 ， 
设计 Font 类 又 是 为 了 预防 泄漏 字体 资 源 的 机 会 的 增长 。 


可 选择 的 办 法 是 为 Font 提供 一 个 隐 式 转换 到 它 的 FontHandle 的 转换 函数 : 


class Font { 
public: 


operator FontHandle() const { return f; } // implicit conversion function 


ps 


这 样 就 可 以 使 对 C API 的 调用 简单 而 自然 : 


Font f(getFont()); 
int newFontSize; 


changeFontSize(f, newFontSize); // implicitly convert Font 
// to FontHandle 


不 利 的 方面 是 隐 式 转换 增加 了 错误 的 机 会 。 例 如 ， 一 个 客户 可 能 会 在 有 意 使 用 Font 的 地 方 意 
外 地 产生 一 个 FontHandle : 


Font fi(getFont()); 


FontHandle f2 = f1; // oops! meant to copy a Font 
// object, but instead implicitly 
// converted f1 into its underlying 
// FontHandle, then copied that 


现在 ， 程 序 有 了 一 个 被 Font 对 象 f1 管理 的 FontHandle， 但 是 这 个 FontHandle 也 能 通过 直 
接 使 用 f2 来 加 以 利用 。 这 几乎 绝对 不 会 成 为 什么 好 事 。 例 如 ， 当 f1 被 销毁 ， 字 体 将 被 释放 ， 
f2 则 被 悬挂 (dangle) 。 


关于 是 否 提供 从 一 个 RAII 类 到 它 的 底层 资源 的 显 式 转换 (例如 ， 通 过 一 个 get MAMA) 或 
者 允许 隐 式 转换 的 决定 ， 要 依靠 RA 类 被 设计 履行 的 具体 任务 和 它 被 计划 使 用 的 细节 而 做 
出 。 最 好 的 设计 很 可 能 就 是 坚持 Item 18 的 建议 (使 接口 易于 正确 使 用 ， 而 难以 错误 使 用 ) 的 
那 一 个 。 通常 ， 类 似 get 的 一 个 显 式 转换 函数 是 更 可 取 的 方式 ， 因 为 它 将 意外 的 类 型 转换 的 
机 会 减 到 最 少 。 偶 尔 的 ， 通 过 隐 式 类 型 转换 提高 使 用 的 自然 性 将 使 天 平 向 那个 方向 倾斜 。 


(RO ALBA Riel, BBOREl—~* RAI 类 内 部 的 裸 资源 破坏 了 封装 。 这 是 正确 的 ， 但 这 并 非 
像 它 开 始 看 上 去 那样 是 个 设计 的 祸患 。RAII 类 的 存在 并 非 为 了 封装 什么 未 西 ; 它 的 存在 是 为 
了 确保 一 个 特殊 的 动作 一 一 资源 释放 一 一 的 发 生 。 如 果 你 希望 ， 封 装 资源 的 地 位 也 可 以 提高 
到 这 个 主要 功能 之 上 ， 但 这 并 非 必需 。 此 外 ， 一 些 RA 类 将 实现 的 真正 封装 和 底层 资源 的 非 
常 宽松 的 封装 结合 在 一 起 。 例 如 ，tr1::shared_ptr 封装 了 它 的 引用 计数 的 全 部 机 制 ， 但 它 依然 
提供 对 它 所 包含 的 资源 的 简单 访问 。 就 像 大 多 数 设 计 良 好 的 类 ， 它 隐藏 了 客户 不 需要 看 到 
的 ， 但 它 也 让 客户 的 确 需要 访问 的 那些 东西 可 以 利用 。 


Things to Remember 
。 API 经 常 需要 访问 裸 资 源 ， 所 以 每 一 个 RAII 类 都 应 该 提供 取得 它 所 管理 的 资源 的 方法 。 


。 访问 可 以 通过 显 式 转换 或 者 隐 式 转换 进行 。 通 常 ， 显 式 转 换 更 安全 ， 而 隐 式 转换 对 客户 
来 说 更 方便 。 


Item 16: 使 用 相同 形式 的 new 和 delete 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


下 面 这 段 代 码 有 什么 问题 ? 


std::string *stringArray = new std::string[100]; 


delete stringArray; 


每 件 事 看 起 来 都 很 正常 。 也 为 new 搭配 了 一 个 delete。 但 是 ， 仍 然 有 某 件 事 情 彻底 错 了 。 程 
序 的 行为 是 未 定义 的 。 直 到 最 后 ，stringArray 指向 的 100 个 string 对 象 中 的 99 个 不 太 可 能 
被 完全 销毁 ， 因 为 它们 的 析 构 本 数 或 许 根本 没有 被 调用 。 


当 你 使 用 了 一 个 new 表达 式 (也 就 是 说 ， 通 过 使 用 new 0 ， 有 两 件 事情 会 
RE, BH, DEAE 〈 通 过 一 个 被 称 基 参见 Item 49 #151) 。 第 
二 ， 一 个 或 多 个 构造 画 数 在 这 些 内 存 上 被 调用 。 当 你 使 用 一 eas 表达 式 (也 就 是 说 ， 使 
用 delete) ， 有 另外 的 两 件 事情 会 发 生 : ee 9 数 在 这 些 内 存 上 被 调用 ， 然 后 内 

存 被 回收 (通过 一 个 被 称 六 见 ltem 51) 。 对 于 delete 来 说 有 

一 个 大 问题 : ee eee 题 的 答案 将 决定 有 多 少 个 

析 构 函数 必须 被 调用 。 








事实 上 ， 问 题 很 简单 : 将 要 被 删除 的 指针 是 指向 一 个 单一 的 对 象 还 是 一 个 对 象 的 数组 ? 这 是 
一 个 关键 的 问题 ， 因 为 单一 对 象 的 内 存 布局 通常 不 同 于 数组 的 内 存 布局 。 详 细 地 说 ， 一 个 数 
组 的 内 存 布局 通常 包含 数组 的 大 小 ， 这 样 可 以 使 得 delete 更 容易 知道 有 多 少 个 析 构 函数 需要 
被 调用 。 而 一 个 单一 对 象 的 内 存 中 缺乏 这 个 信息 。 你 可 以 认为 不 同 的 内 存 布局 看 起 来 如 下 
图 ， 那 个 n 就 是 数组 的 大 小 : 


Single : 
Object Object | 


Array | n | Object | Object | Object | ~ 





这 当然 只 是 一 个 例子 。 编译 器 并 不 是 必须 这 文 样 实 现 My 虽然 很 多 是 这 样 的 。 


当 你 对 一 个 指针 使 用 delete, delete 知道 是 否 有 数组 大 小 信息 的 唯一 方法 就 是 由 你 来 告诉 
它 。 如 果 你 在 你 使 用 的 delete 中 加 入 了 方 括号 ，delete 就 假设 那个 指针 指向 的 是 一 个 数组 。 
否则 ， 就 假设 指向 一 个 单一 的 对 象 。 


std::string *stringPtri = new std::string; 


std::string *stringPtr2 = new std::string[100]; 


delete stringPtr1; // delete an object 


delete [] stringPtr2; // delete an array of objects 


如 果 你 对 stringPtr1 使 用 了 [ 形式 会 发 生 什么 呢 ? 结果 是 未 定义 的 ， 但 不 太 可 能 是 什么 好 

事 。 假 设 如 上 图 的 布局 ，delete 将 读 入 某 些 内 存 的 内 容 并 将 其 看 作 一 个 数组 的 大 小 ， 然 后 开 

始 调用 那么 多 析 构 画 数 ， 不 仅 全 然 不 顾 它 在 其 上 工作 的 内 存 不 是 数组 ， 而 且 还 可 能 忘掉 了 它 
正 忙 着 析 构 的 对 象 的 类 型 。 


如 果 你 对 stringPtr2 没有 使 用 [形式 会 发 生 什 么 呢 ? 也 是 未 定义 的 ， 只 不 过 你 不 会 看 到 它 
Sle SAA MBAR. WA, SFR int 的 内 建 类 型 其 结果 也 是 未 定义 的 《而且 有 时 
EASA) ， 即 使 这 样 的 类 型 没有 析 构 图 数 。 


规则 很 简单 。 如 果 你 在 new 表达 式 中 使 用 了 []， 你 也 必须 在 相应 的 delete 表达 式 中 使 用 []。 
如 果 你 在 new 表达 式 中 没有 使 用 []， 在 匹配 的 delete 表达 式 中 也 不 要 使 用 []。 


当 你 写 的 一 个 类 中 包含 一 个 指向 动态 分 配 的 内 存 的 指针 ， 而 且 提供 了 多 个 构造 本 数 的 时 候 ， 
这 条 规则 尤其 重要 ， 上 应 锡 刻 脑海 ， 因 为 那 时 你 必须 小 心地 在 所 有 的 构造 函数 中 使 用 相同 形式 
的 new 初始 化 那个 指针 成 员 。 如 果 你 不 这 样 做 ， 你 怎么 知道 在 你 的 析 构 范 数 中 应 该 使 用 哪 种 
形式 的 delete IE ? 


这 个 规则 对 于 有 typedef 倾向 的 人 也 很 值得 注目 ， 因 为 这 意味 着 一 个 typedef 的 作者 必须 在 文 
档 中 记录 : 当 用 new 生成 一 个 typedef 类 型 的 对 象 时 ， 应 该 使 用 哪 种 形式 的 delete。 例 如 ， 
考虑 这 个 typedef : 


typedef std::string AddressLines[4]; // a person's address has 4 lines, 
// each of which is a string 


因为 AddressLines 是 一 个 数组 ， 这 里 使 用 new, 


std::string *pal = new AddressLines; // note that "new AddressLines" 
// returns a string*, just like 
// “new string[4]" would 


必须 用 delete 的 数组 形式 进行 匹配 : 


delete pal; // undefined! 


delete [] pal; // fine 


为 了 避免 这 种 混淆 ， 要 克制 对 数组 类 型 使 用 typedef。 那 很 简单 ， 因 为 标准 C++ 库 (参见 
ltem 54) 包含 string 和 vector， 而 且 那 些 模 板 将 对 动态 分 配 数组 的 需要 减少 到 几乎 为 需 。 例 
如 ， 这 里 ，AddressLines 可 以 被 定义 为 一 个 string 的 vector， 也 就 是 说 ， 类 型 为 


vector<string>。 
Things to Remember 


。 如 果 你 在 new 表达 式 中 使 用 了 []， 你 必须 在 对 应 的 delete 表达 式 中 使 用 []。 如 果 你 在 
new 表达 式 中 没有 使 用 []， 你 也 不 必 在 对 应 的 delete 表达 式 中 不 使 用 []。 


Item 17: 在 一 个 独立 的 语句 中 将 new 出 来 的 对 象 存 
A 3 Bets H+ 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


假设 我 们 有 一 个 函数 取得 我 们 的 处 理 优先 级 ， 而 第 二 个 函数 根据 优先 级 针对 动态 分 配 的 
Widget 做 一 些 处 理 : 


int priority(); 


void processWidget(std::tri::shared_ptr&lt;Widget&gt; pw, int priority); 
要 忘记 使 用 对 象 管理 资源 的 至 理 名 言 (参见 Item 13) , processWidget 为 处 理 动态 分 配 的 
Gai 使 用 了 一 个 智能 指针 (在 此 ， 是 一 个 tr1::shared_ptr) 。 


现在 考虑 一 个 对 processWidget 的 调用 : 


processWidget(new Widget, priority()); 


且慢 ， 别 想 这 样 调用 。 它 不 能 编译 。tr1::shared_ptr 的 构造 函数 取得 一 个 裸 指针 (raw 
pointer) 应 该 是 显 式 的 ， 所 以 不 能 从 一 个 由 "new Widget" 返回 的 裸 指针 隐 式 转型 到 
processWidget 所 需要 的 tr1::shared_ptr。 下 面 的 代码 ， 无 论 如 何 ， 是 可 以 编译 的 : 


processWidget(std::tri::shared_ptr<Widget>(new Widget), priority()); 
合 人 惊讶 的 是 ， 尽 管 我 们 在 这 里 各 处 都 使 用 了 对 象 管理 资源 ， 这 个 调用 还 是 可 能 泄漏 资源 。 
下 面 就 来 说 明 这 是 如 何 发 生 的 。 


在 编译 器 能 生成 一 个 对 processWidget 的 调用 之 前 ， 它 们 必须 传递 实际 参数 来 计算 形式 参数 
的 值 。 第 二 个 实际 参数 不 过 是 对 函数 priority 的 调用 ， 但 是 第 一 个 实际 参数 
("std::tr1::shared_ptr<Widget>(new Widget)") ， 由 两 部 分 组 成 


e 表达 式 "new Widget" 的 执行 。 
e 一 个 对 tr1::shared_ptr 的 构造 画 数 的 调用 。 
在 processWidget 能 被 调用 之 前 ， 编 译 器 必须 为 这 三 件 事情 生成 代码 : 


e 调用 priority. 


e 执行 "new Widget". 
e 调用 tr1::shared_ptr HJ ERZ 


C++ 编译 器 允许 在 一 个 相当 大 的 范围 内 决定 这 三 件 事 被 完成 的 顺序 。 (这 里 与 Java 和 C# 等 
语言 的 处 理 方式 不 同 ， 那 些 语 言 里 画 数 参数 总 是 按照 一 个 精确 的 顺序 被 计算 。) "new Widget" 
表达 式 一 定 在 tr1::shared_ptr 的 构造 本 数 能 被 调用 之 前 执行 ， 因 为 这 个 表达 式 的 结果 要 作为 
一 个 参数 传递 给 tr1::shared_ptr Mis HRM, (BÆ priority 的 调用 可 以 被 第 一 个 ， 第 二 个 或 第 
三 个 执行 。 如 果 编 译 器 选择 第 二 个 执行 它 (大 概 这 祥 能 使 它们 生成 更 有 效率 的 代码 ) ， 我 们 
最 终 得 到 这 样 一 个 操作 顺序 : 


1. 执行 "new Widget"。 
2. 调用 priority。 
3. 调用 tr1::shared_ptr 的 构造 画 数 。 


但 是 请 考虑 ， 如 果 对 priority 的 调用 引发 一 个 异常 将 发 生 什 么 。 在 这 种 情况 下 ， 从 "new 
Widget" 返回 的 指针 被 丢失 ， 因 为 它 没有 被 存 和 我们 期 望 能 阻止 资源 泄漏 的 tr1::shared_ptr. 
由 于 一 个 异常 可 能 插入 资源 创建 的 时 间 和 将 资源 交 给 一 个 资源 管理 对 象 的 时 间 之 间 ， 所 以 调 
用 processWidget 可 能 会 发 生 一 次 泄漏 。 


避免 类 似 问 题 的 方法 很 简单 : 用 一 个 单独 的 语句 创建 Widget 并 将 它 存 入 一 个 智能 指针 ， 然 后 
将 这 个 智能 指针 传递 给 processWidget : 
std::tri::shared_ptr<Widget> pw(new Widget); // store newed object 
/ 


/ in a smart pointer ina 
// standalone statement 


~ 


processWidget(pw, priority()); // this call won't leak 


这 样 做 是 因为 编译 器 在 不 同 的 语句 之 间 重 新 安排 操作 顺序 的 活动 余地 上 比 在 一 个 语句 之 内 要 小 
得 多 。"new Widget" 表达 式 和 tr1::shared_ptr 的 构造 函数 的 调用 与 priority 的 调用 在 不 同 的 语 
句 中 ， 所 以 编译 器 不 会 允许 priority 的 调用 插入 它们 中 间 。 


Things to Remember 


。 在 一 个 独立 的 语句 中 将 new 出 来 的 对 象 存 和 智能 指针 。 如 果 玻 忽 了 这 一 点 ， 当 异常 发 生 
时 ， 可 能 引起 微妙 的 资源 泄漏 。 


Item 18: 使 接口 易于 正确 使 用 ， 而 难以 错误 使 用 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


C++ 被 淹没 于 接口 中 。 画 数 接口 、 类 接口 、 模 板 接口 。 每 一 个 接口 都 意味 着 客户 的 代码 和 你 
的 代码 互相 影响 。 假 设 你 在 和 通 情 达 理 的 人 打交道 ， 那 些 客 户 也 想 做 好 工作 。 他 们 想 要 正确 
使 用 你 的 接口 。 在 这 种 情况 下 ， 如 果 他 们 犯 了 一 个 错误 ， 就 说 明 你 的 接口 至 少 有 部 分 是 不 完 
善 的 。 在 理想 情况 下 ， 如 果 一 个 接口 的 一 种 尝试 的 用 法 不 符合 客户 的 预期 ， 代 码 将 无 法 编 
译 ， 反 过 来 ， 如 果 代 码 可 以 编译 ， 那 么 它 做 的 就 是 客户 想 要 的 。 


开发 易于 正确 使 用 ， 而 难以 错误 使 用 的 接口 需要 你 考虑 客户 可 能 造成 的 各 种 错误 。 例 如 ， 假 
设 你 正在 设计 一 个 代表 时 间 的 类 的 构造 范 数 : 


class Date { 
public: 
Date(int month, int day, int year); 


oe 


匆匆 一 看 ， 这 个 接口 似乎 是 合乎 情理 的 〈 至 少 在 美国 ) ， 但 是 客户 可 能 很 容易 地 造成 两 种 错 
误 。 首 先 ， 他 们 可 能 会 以 错误 的 顺序 传递 参数 : 


Date d(30, 3, 1995); // Oops! Should be "3, 30" , not "30, 3" 


第 二 ， 他 们 可 能 传递 一 个 非法 的 代表 月 或 日 的 数字 : 

Date d(2, 20, 1995); // Oops! Should be "3, 30" , not "2, 20" 

(后 面 这 个 例子 看 上 去 好 像 没 什么 ， 但 是 想 想 键 盘 上 ，2 就 在 3 的 旁边 ， 这 种 "off by one" 类 
型 的 错误 并 不 罕见 。) 


很 多 客户 错误 都 可 以 通过 引入 新 的 类 型 来 预防 。 确 实 ， 类 型 系统 是 你 阻止 那些 不 合适 的 代码 
通过 编译 的 主要 支持 者 。 在 当前 情况 下 ， 我 们 可 以 引入 简单 的 包装 类 型 来 区 别 日 ， 月 和 年 ， 
并 将 这 些 类 型 用 于 Data 的 构造 酚 数 。 


struct Day { struct Month { struct Year { 


explicit Day(int d) explicit Month(int m) explicit Year(int y) 
:val(d) {} :val(m) {} :val(y) {} 
int val; int val; int val; 

J; }; }; 


class Date { 
public: 
Date(const Month& m, const Day& d, const Year& y); 


J; 

Date d(30, 3, 1995); // error! wrong types 

Date d(Day(30), Month(3), Year(1995)); // error! wrong types 

Date d(Month(3), Day(30), Year(1995)); // okay, types are correct 


将 日 ， 月 和 年 做 成 封装 数据 的 羽翼 丰满 的 类 上 比 上 面 的 简单 地 使 用 struct 更 好 (参见 Item 
22) ， 但 是 即使 是 struct 也 足够 证 明明 智 地 引 和 新 类 型 在 阻止 接口 的 错误 使 用 方面 能 工作 得 
非常 出 色 。 


只 要 放置 了 正确 的 类 型 ， 它 往往 能 合理 地 限制 那些 类 型 的 值 。 例 如 ， 月 公有 12 个 合法 值 ， 所 
以 Month 类 型 应 该 反映 这 一 点 。 | 这 一 点 的 一 种 方法 是 用 一 个 枚 举 来 表现 月 ， 但 是 枚 举 不 
像 我 们 希望 的 那样 是 类 型 安全 (type-safe) 的 。 例 如 ， 枚 举 能 被 作为 整数 使 用 (参见 Item 
2) 。 一 个 安全 的 解决 方案 是 预先 确定 合法 的 Month 的 集合 : 


class Month { 

public: 
static Month Jan() { return Month(1); } // functions returning all valid 
static Month Feb() { return Month(2); } // Month values; see below for 
San // why these are functions, not 
static Month Dec() { return Month(12); } // objects 


// other member functions 
private: 
explicit Month(int m); // prevent creation of new 
// Month values 


// month-specific data 


}; 
Date d(Month::Mar(), Day(30), Year(1995)); 


OR AAAS t RRR ARERR RA, AURA Ais SIERRA HR 
(non-local static objects) 的 初始 化 的 可 靠 性 是 值得 REEL. Item 4 能 唤起 你 的 记忆 。 


防止 可 能 的 客户 错误 的 另 一 个 方法 是 限制 对 一 个 类 型 能 够 做 的 事情 。 施 加 限制 的 一 个 普通 方 
法 就 是 加 上 const。 例 如 ，ltem 3 解释 了 使 operator 的 返回 类 型 具有 const 资格 是 如 何 能 够 
防止 客户 对 用 户 自 定义 类 型 犯 下 这 样 的 错误 : 


if (a * b=c) ... // oops, meant to do a comparison! 


实际 上 ， 这 仅仅 是 另 一 条 使 关 型 易于 正确 使 用 而 难以 错误 使 用 的 普通 方针 的 一 种 表现 : 除非 
你 有 很 棒 的 理由 ， 否 则 就 让 你 的 类 型 的 行为 与 内 建 类 型 保持 一 致 。 客 户 已 经 知道 像 int 这 样 的 
类 型 如 何 表 现 ， 所 以 你 应 该 努力 使 你 的 类 型 的 表现 无 论 何 时 都 同样 合理 。 例 如 ， 如 果 a 和 b 
是 int， 给 a*b 赋值 是 非法 的 。 所 以 除非 有 一 个 非常 棒 理由 脱离 这 种 表现 ， 否 则 ， 对 你 的 类 型 
来 说 这 样 做 也 应 该 是 非法 的 。 


避免 和 内 建 类 型 富 无 理由 的 不 相 容 的 真正 原因 是 为 了 提供 行为 一 致 的 接口 。 很 少 有 特性 比 一 
致 性 更 易于 引出 易于 使 用 的 接口 ， 也 很 少 有 特性 比 不 一 致 性 更 易于 引出 邻 人 郁闷 的 接口 。STL 
容器 的 接口 在 很 大 程度 上 〈 虽 然 并 不 完美 ) 是 一 致 的， 而 且 这 使 得 它们 相当 易于 使 用 。 例 

如 ， 每 一 种 STL 容器 都 有 一 个 名 为 size 的 成 员 辑 数 可 以 知道 容器 中 有 多 少 对 象 。 与 此 对 上 比 的 
是 Java， 在 那里 你 对 数组 使 用 length 属性 ， 对 String 使 用 length 方法 ， 而 对 List 却 要 使 用 
size 方法 ， 在 .NET 中 ，Array 有 一 个 名 为 Length 的 属性 ， 而 ArrayList 却 有 一 个 名 为 Count 
的 属性 。 一 些 开 发 人 员 认 为 集成 开发 环境 (IDES) 能 补偿 这 些 琐 细 的 矛盾 ， 但 他 们 错 了 。 矛 
盾 在 开发 者 工作 中 强加 的 精神 折磨 是 任何 IDE 都 无 法 完全 消除 的 。 


任何 一 个 要 求 客 户 记 住 某 些 事情 的 接口 都 是 有 错误 使 用 倾向 的 ， 因 为 客户 可 能 忘记 做 那些 事 
情 。 例 如 ，ltem 13 介绍 了 一 个 factory 画 数 ， 它 返回 一 个 指向 动态 分 配 的 Investment 继承 体 
系 中 的 对 象 的 指针 。 


Investment* createInvestment(); // from Item 13; parameters omitted 
// for simplicity 


为 了 避免 资源 港 漏 ，createlnvestment 返回 的 指针 最 后 必须 被 删除 ， 但 这 就 为 至 少 两 种 类 型 
的 客户 错误 创造 了 机 会 : 删除 指针 失败 ， 或 删除 同一 个 指针 一 次 以 上 。 


ltem 13 展示 了 客户 可 以 怎样 将 createlnvestment 的 返回 值 存 人 一 个 类 似 auto_ptr 或 
tr1::shared _ptr 智能 指针 ， 从 而 将 使 用 delete 的 职责 交 给 智能 指针 。 但 是 如 果 客 户 忘 记 使 用 
智能 指针 呢 ? 在 很 多 情况 下 ， 一 个 更 好 的 接口 会 预先 判定 将 要 出 现 的 问题 ， 从 而 让 factory K 
数 在 第 一 现场 即 返回 一 个 智能 指针 : 


std::tri::shared_ptr<Investment> createInvestment(); 


这 就 从 根本 上 强制 客户 将 返回 值 存 入 一 个 tr1::shared_ptr， 几 乎 完全 消除 了 当 底 层 的 
Investment 对 象 不 再 使 用 的 时 候 忘 记 删 除 的 可 能 性 。 


实际 上 ， 返 回 一 个 tr1::shared_ptr 使 得 接口 的 设计 者 预防 许多 其 它 客户 的 与 资源 泄漏 相关 的 

错误 成 为 可 能 ， 因 为 ， 就 像 ltem 14 解释 的 : 当 一 个 智能 指针 被 创建 的 时 候 ，tr1::shared_ptr 

允许 将 一 个 资源 释放 (resource-release) WH ——— <4 "deleter" 一 一 绑 定 到 智能 指针 上 。 
(auto_ptr 则 没有 这 个 能 力 。) 


假设 从 createlnvestment 得 到 一 个 Investment* 指针 的 客户 期 望 将 这 个 指针 传 给 一 个 名 为 
getRidOfInvestment 的 函数 ， 而 不 是 对 它 使 用 delete。 这 样 一 个 接口 又 为 一 种 新 的 客户 错误 
打开 了 门 ， 这 就 是 客户 可 能 使 用 了 错误 的 资源 析 构 机 制 ( 也 就 是 说 ， 用 了 delete 而 不 是 


getRidOfInvestment) . createlnvestment 的 实现 可 以 通过 返回 一 个 在 它 的 deleter KRET 
getRidOflnvestment 的 tr1::shared_ptr 来 预防 这 个 问题 。 


tr1::shared_ptr 提供 了 一 个 需要 两 个 参数 (要 被 管理 的 指针 和 当 引 用 计数 变 为 需 时 要 调用 的 
deleter) 的 构造 画 数 。 这 里 展示 了 创建 一 个 以 getRidOflnvestment 为 deleter 的 null 
tr1::shared_ptr 的 方法 : 


std::tri::shared_ptr<Investment> // attempt to create a null 
pInv(0, getRidOfInvestment) ; // shared_ptr with a custom deleter; 
// this won't compile 


唉 ， 这 不 是 合法 的 C++。tr1::shared_ptr 的 构造 画 数 坚 决 要 求 它 的 第 一 个 参数 应 该 是 一 个 指 
针 ， 而 0 不 是 一 个 指针 ， 它 是 一 个 int。 当 然 ， 它 能 转型 为 一 个 指针 ， 但 那 在 当前 情况 下 并 不 
够 好 用 ，tr1::shared_ptr 坚决 要 求 一 个 真正 的 指针 。 用 强制 转型 解决 这 个 问题 : 


std::tri::shared_ptr<Investment> // create a null shared_ptr with 
pInv(static_cast<Investment*>(0), // getRidOfInvestment as its 
getRidOfInvestment ) ; // deleter; see Item 27 for info on 


// static_cast 


据 此 ， 实 现 返 回 一 个 以 getRidOfinvestment 作为 deleter 的 tr1::shared_ptr 的 
createlnvestment 的 代码 看 起 来 就 像 这 个 样子 : 


std::tri::shared_ptr<Investment> createInvestment() 


std::tri::shared_ptr<Investment> retVal(static_cast<Investment*>(0), 
getRidOfInvestment) ; 


retVal =... ; // make retVal point to the 
// correct object 


return retVal; 


} 


当然 ， 如 果 将 被 plnv EHAR A AEE plnv 时 被 确定 ， 最 好 是 将 这 个 裸 指针 传 给 
plnv 的 构造 范 数 ， 而 不 是 将 plnv 初始 化 为 null 然后 再 赋值 给 它 。 至 于 方法 上 的 细节 ， 参 考 
ltem 26。 


tr1::shared_ptr 的 一 个 特别 好 的 特性 是 它 自动 逐 指 针 地 使 用 deleter 以 消除 另 一 种 潜在 的 客户 
Fik “cross-DLL 问题 。 "这 个 问题 发 生 在 这 种 情况 下 : 一 个 对 象 在 一 个 动态 链接 库 

(dynamically linked library (DLL)) 中 通过 new 被 创建 ， 在 另 一 个 不 同 的 DLL 中 被 删除 。 在 
许多 平台 上 ， 这 样 的 cross-DLL new/delete 对 会 引起 运行 时 错误 。tr1::shared_ptr 可 以 避免 
这 个 问题 ， 因 为 它 的 缺 省 的 deleter 只 将 delete 用 于 这 个 tr1::shared_ptr 被 创建 的 DLL 中 。 
这 就 意味 着 ， 例 如 ， 如 果 Stock 是 一 个 继承 自 Investment 的 类 ， 而 且 createlnvestment 被 实 
现 如 下 ， 





std::tri::shared_ptr<Investment> createInvestment() 


return std::tri::shared_ptr<Investment>(new Stock); 


返回 的 tr1::shared_ptr 能 在 DLL 之 间 进 行 传递 ， 而 不 必 关 心 cross-DLL 问题 。 指 向 这 个 
Stock 的 tr1::shared_ptr 将 保持 对 “ 当 这 个 Stock 的 引用 计数 变 为 需 的 时 候 ， 哪 一 个 DLL 的 
delete 应 该 被 使 用 "的 跟踪 。 


这 个 Item 不 是 关于 tr1::shared_ptr 的 一 一 而 是 关于 使 接口 易于 正确 使 用 ， 而 难以 错误 使 用 的 
一 一 但 tr1::shared_ptr 正 是 这 样 一 个 消除 某 些 客户 错误 的 简单 方法 ， 值 得 用 一 个 概述 来 看 看 
使 用 它 的 代价 。 最 通用 的 tr1::shared_ptr 实现 来 自 于 Boost (参见 Item 55) 。Boost 的 
shared_ptr 的 大 小 是 裸 指针 的 两 售 ， 将 动态 分 配 内 存 用 于 簿 记 和 deleter 专用 (deleter- 
specific) 数据 ， 当 调用 它 的 deleter 时 使 用 一 个 虚 函 数 来 调用 ， 在 一 个 它 认 为 是 多 线程 的 应 
用 程序 中 ， 当 引用 计数 被 改变 ， 会 导致 线程 同步 开销 。 (你 可 以 通过 定义 一 个 预 处 理 符号 来 
使 多 线程 支持 失效 。) 在 缺点 方面 ， 它 比 一 个 裸 指 针 大 ， 比 一 个 裸 指 针 慢 ， 而 且 要 使 用 辅助 
的 动态 内 存 。 在 许多 应 用 程序 中 ， 这 些 附加 的 运行 时 开销 并 不 显著 ， 而 对 客户 错误 的 减少 却 
是 每 一 个 人 都 看 得 见 的 。 


Things to Remember 
。 好 的 接口 易于 正确 使 用 ， 而 难以 错误 使 用 。 你 应 该 在 你 的 所 有 接口 中 为 这 个 特性 努力 。 
。 使 易于 正确 使 用 的 方法 包括 在 接口 和 行为 兼容 性 上 与 内 建 类 型 保持 一 致 。 


预防 错误 的 方法 包括 创建 新 的 类 型 ， 限 定 类 型 的 操作 ， 约 束 对 象 的 值 ， 以 及 消除 客户 的 


资源 管理 职责 。 


e tr1::shared_ptr 支持 自 定义 deleter。 这 可 以 防止 cross-DLL 问题 ， 能 用 于 自动 解锁 互 斥 
体 (参见 ltem 14) 等 。 


a ` ` 2 ` ` x > 2 | x x 
Item 19: 视 类 设计 为 类 型 设计 
作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


在 C++ 中， 就 像 其 它 面 向 对 象 编程 语言 ， 可 以 通过 定义 一 个 新 的 类 来 定义 一 个 新 的 类 型 。 作 
为 一 个 C++ 开发 者 ， 你 的 大 量 时 间 就 这 样 花费 在 增 大 你 的 类 型 系统 。 这 意味 着 你 不 仅仅 是 一 
个 类 的 设计 者 ， 而 且 是 一 个 类 型 的 设计 者 。 重 载 加 数 和 运算 符 ， 控 制 内 存 分 配 和 回收 ， 定 叉 
对 象 的 初始 化 和 终结 过 程 一 一 这 些 全 在 你 的 掌控 之 中 。 因 此 你 应 该 在 类 设计 中 倾注 大 量 心 
血 ， 接 近 语 言 设计 者 在 语言 内 建 类 型 的 设计 中 所 倾注 的 大 量 心 血 。 


设计 良好 的 类 是 有 挑战 性 的 ， 因 为 设计 良好 的 类 型 是 有 挑战 性 的 。 良 好 的 类 型 拥有 简单 自然 
的 语法 ， 符 合 直 觉 的 语义 ， 以 及 一 个 或 更 多 高 效 的 实现 。 在 C++ 中 ， 一 个 缺乏 计划 的 类 设 
计 ， 使 其 不 可 能 达到 上 述 任何 一 个 目标 。 基 至 一 个 类 的 成 员 本 数 的 执行 特性 可 能 受到 它们 是 
被 如 何 声明 的 影响 。 
那么 ， 如 何 才能 设计 高 效 的 类 呢 ? 首先 ， 你 必须 理解 你 所 面 对 的 问题 。 实 际 上 每 一 个 类 都 需 
要 你 面 对 下 面 这 些 问题 ， 其 答案 通常 就 导向 你 的 设计 的 限制 因素 : 

。 你 的 新 类 型 的 对 象 应 该 如 何 创 建 和 销毁 ? 如 何 做 这 些 将 影响 到 你 的 类 的 构造 画 数 和 析 构 


函数 ， 以 及 内 存 分 配 和 回收 的 函数 (operator new, operator new[]，operator delete, 
和 operator delete[] 参见 Chapter 8) 的 设计 ， 除 非 你 不 写 它 们 。 





© 对 象 的 初始 化 和 对 象 的 赋值 应 该 有 什么 不 同 ? 这 个 问题 的 答案 决定 了 你 的 构造 函数 和 你 
的 赋值 运算 符 的 行为 和 它们 之 间 的 不 同 。 这 对 于 不 混淆 初始 化 和 赋值 是 很 重要 的 ， 因 为 
它们 相当 于 不 同 的 函数 调用 (参见 ltem 4) 。 


e 以 值 传递 (passed by value) 对 于 你 的 新 类 型 的 对 象 意味 着 什么 ? 记 住 ， 拷 贝 构 造 琅 数 
定义 了 一 个 新 类 型 的 传 值 (pass-by-value) 如 何 实现 。 


你 的 新 类 型 的 合法 值 的 限定 条 件 是 什么 ? 通常， 对 于 一 个 类 的 数据 成 员 来 说 ， 仅 有 某 些 
值 的 组 合 是 合法 的 。 那 些 组 合 决定 了 你 的 类 必须 维持 的 不 变量 。 这 些 不 变量 决定 了 你 必 
须 在 成 员 函 数 内 部 进行 错误 检查 ， 特 别 是 你 的 构造 画 数 ， 赋 值 运算 符 ， 以 及 "setter" E 
数 。 它 可 能 也 会 影响 你 的 函数 抛 出 的 异常 ， 以 及 你 的 画 数 的 异常 规范 (exception 
specification) 〈 你 用 到 它 的 可 能 性 很 小 ) 。 


你 的 新 类 型 是 否 适合 放 进 一 个 继承 图 表 中 ? 如 果 你 从 已 经 存在 的 类 继承 ， 你 将 被 那些 类 

的 设计 所 约束 ， 特 别 是 它们 的 函数 是 virtual 还 是 non-virtual (参见 Item 34 和 36) 。 如 
果 你 希望 允许 其 他 类 继承 你 的 类 ， 将 影响 到 你 是 否 将 函数 声明 为 virtual， 特 别 是 你 的 析 

构图 数 (参见 tem 7) 。 


。 你 的 新 类 型 允许 哪 种 类 型 转换 ?你 的 类 型 身 处 其 它 类 型 的 海洋 中 ， 所 以 是 否 要 在 你 的 类 
型 和 其 它 类 型 之 间 有 一 些 转 换 ? 如 果 你 希望 允许 T1 类 型 的 对 象 隐 式 转型 为 T2 类 型 的 对 
象 ， 你 就 要 么 在 T1 类 中 写 一 个 类 型 转换 范 数 (例如 ，operator T2) ， 要 么 在 T2 类 中 写 
一 个 非 显 式 的 构造 画 数 ， 而 且 它 们 都 要 能 够 以 单一 参数 调用 。 如 果 你 希望 仅仅 人 允许 显示 
转换 ， 你 就 要 写 执 行 这 个 转换 的 辑 数 ， 而 且 你 还 需要 避免 使 它们 的 类 型 转换 运算 符 或 非 
显 式 构造 画 数 能 够 以 一 个 参数 调用 。 (作为 一 个 既 人 允许 隐 式 转换 又 允许 显 式 转换 的 例 
子 ， 参 见 ltem 15。) 


e。 对 于 新 类 型 哪些 运算 符 和 回 数 有 意义 ?这 个 问题 的 答案 决定 你 应 该 为 你 的 类 声明 哪些 函 
数 。 其 中 一 些 是 成 员 画 数 ， 另 一 些 不 是 (BR Item 23、24 和 46) 。 


。 哪些 标准 函数 不 应 该 被 接受 ? 你 需要 将 那些 都 声明 为 private (参见 ltem 6) 。 


e 你 的 新 类 型 中 哪些 成 员 可 以 被 访问 ? 这 个 问题 的 可 以 帮助 你 决定 哪些 成 员 是 public, wpe 
是 protected， 以 及 哪些 是 private。 它 也 可 以 帮助 你 决定 哪些 类 和 .或 函数 应 该 是 友 元 ， 
以 及 一 个 类 岂 套 在 另 一 个 类 内 部 是 否 有 意义 。 


什么 是 你 的 新 类 型 的 "undeclared interface"? 它 对 于 性 能 考虑 ， 异 常安 全 (exception 
safety) (参见 ltem 29) ， 以 及 资源 使 用 (例如 ， 锁 和 动态 内 存 ) 提供 哪 种 保证 ? 你 在 
这 些 领 域 提 供 的 保证 将 强制 影响 你 的 类 的 实现 。 

你 的 新 类 型 有 多 大 程度 的 通用 性 ?也许 你 并 非 真 的 要 定义 一 个 新 的 类 型 。 也 许 你 要 定义 
一 个 整个 的 类 型 家 族 。 如 果 是 这 样 ， 你 不 需要 定义 一 个 新 的 类 ， 而 是 需要 定义 一 个 新 的 
类 模板 。 


。 一 个 新 的 类 型 真 的 是 你 所 需要 的 吗 ?是否 你 可 以 仅仅 定义 一 个 新 的 继承 类 ， 以 便 让 你 可 
以 为 一 个 已 存在 的 类 增加 一 些 功能 ， 也 许 通 过 简单 地 定义 一 个 或 更 多 非 成 员 函 数 或 模板 
能 更 好 地 达成 你 的 目标 。 


回答 这 些 问题 是 困难 的 ， 所 以 定义 高 效 的 类 是 有 挑战 性 的 。 既 然 ， 在 C++ 中 用 户 自 定义 类 生 
成 的 类 型 至 少 可 以 和 内 建 类 型 一 样 好 ， 那 就 做 好 它 ， 它 会 使 一 切 努 力 都 变 的 有 价值 。 


Things to Remember 


e 类 设计 就 是 类 型 设计 。 定 义 一 个 新 类 型 之 前 ， 确 保 考虑 了 本 ltem 讨论 的 所 有 问题 。 


Item 20: 用 pass-by-reference-to-const 〈 传 引用 
给 const) 取代 pass-by-value ( 传 值 ) 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


缺 省 情况 下 ，C++ 以 传 值 方式 将 对 象 传人 或 传 出 本 数 〈 这 是 一 个 从 C 继承 来 的 特性 ) 。 除 非 
你 特别 指定 其 它 方式 ， 否 则 画 数 的 参数 就 会 以 实际 参数 (actual argument) 的 拷贝 进行 初始 
化 ， 而 函数 的 调用 者 会 收 到 函数 返回 值 的 一 个 拷贝 。 这 个 拷贝 由 对 象 的 拷贝 构造 画 数 生成 。 
这 就 使 得 传 值 (pass-by-value) 成 为 一 个 代价 不 菲 的 操作 。 例 如 ， 考 虑 下 面 这 个 类 层级 结 
构 : 


class Person { 


public: 
Person(); // parameters omitted for simplicity 
virtual ~Person(); // see Item 7 for why this is virtual 
private: 


std::string name; 
std::string address; 


}; 


class Student: public Person { 

public: 
Student(); // parameters again omitted 
virtual ~Student(); 


private: 
std::string schoolName; 
std::string schoolAddress; 


}; 


现在 ， 考 虑 以 下 代码 ， 在 此 我 们 调用 一 个 函数 一 一 validateStudent， 它 得 到 一 个 Student 参 
数 (以 传 值 的 方式 ) ， 并 返回 它 是 否 验证 有 效 的 结 


bool validateStudent(Student s); // function taking a Student 
// by value 
Student plato; // Plato studied under Socrates 


bool platoIsOK = validateStudent(plato) ; // call the function 


当 这 个 函数 被 调用 时 会 发 生 什 么 呢 ? 


很 明显 ，Student 的 拷贝 构造 函数 被 调用 ， 用 plato 来 初始 化 参数 s。 同 样 明显 的 是 ， 当 
validateStudent 返回 时 ，s 就 会 被 销毁 。 所 以 这 个 画 数 的 参数 传递 代价 是 一 次 Student 的 拷贝 
构造 画 数 的 调用 和 一 次 Student 的 析 构 函数 的 调用 。 


但 这 还 不 是 全 部 。 一 个 Student 对 象 内 部 包含 两 个 string 对 象 ， 所 以 每 次 你 构造 一 个 Student 
对 象 的 时 候 ， 你 也 必须 构造 两 个 string 对 象 。 一 个 Student 对 象 还 要 从 一 个 Person 对 象 继 
承 ， 所 以 每 次 你 构造 一 个 Student 对 象 的 时 候 ， 你 也 必须 构造 一 个 Person 对 象 。 一 个 
Person 对 象 内 部 又 包含 两 个 额外 的 string 对 象 ， 所 以 每 个 Person 的 构造 也 承担 着 另外 两 个 
string 的 构造 。 最 终 ， 以 传 值 方式 传递 一 个 Student 对 象 的 后 果 就 是 引起 一 次 Student 的 拷贝 
构造 图 数 的 调用 ， 一 次 Person 的 拷贝 构造 本 数 的 调用 ， 以 及 四 次 string 的 拷贝 构造 画 数 调 
用 。 当 Student 对 象 的 拷贝 被 销毁 时 ， 每 一 个 构造 本 数 的 调用 都 对 应 一 个 析 构 画 数 的 调用 ， 

所 以 以 传 值 方式 传递 一 个 Student MHERBAMENT His BBA TH HR | 


好 了 ， 这 是 正确 的 和 值得 的 行为 。 毕竟 ， 你 希望 你 的 全 部 对 象 都 得 到 可 靠 的 初始 化 和 和 销毁。 
尽管 如 此 ， 如 果 有 一 种 办 法 可 以 绕 过 所 有 这 些 构造 和 析 构 过 程 ， 应 该 变 得 更 好 ， 这 就 是 : 传 
引用 给 const (pass by reference-to-const) 


bool validateStudent(const Student& s); 


这 样 做 非常 有 效 : RASH ANA, AARAMM IRR MIS. RIEA 
的 参数 声明 中 的 const 是 非常 重要 的 。validateStudent 的 最 初版 本 接受 一 个 Student 值 参 
数 ， 所 以 调用 者 知道 它们 屏 艾 函数 对 它们 传 入 的 Student 的 任何 可 能 的 改变 ; 
validateStudent 也 只 能 改变 它 的 一 个 拷贝 。 现 在 Student 以 引用 方式 传递 ， 同 时 将 它 声明 为 
const 是 必要 的 ， 否 则 调用 者 必然 担心 validateStudent 改变 了 它们 传人 的 Student. 


以 传 引用 方式 传递 参数 还 可 以 避免 切断 问题 (slicing problem) 。 当 一 个 派生 类 对 象 作为 一 个 
基 类 对 象 被 传递 〈 传 值 方式 ) , Ln settee 个 
么 可 吃惊 的 ， 因 
p a ed de 
图 形 窗口 系统 的 类 上 工作 : 








class Window { 


public: 
std::string name() const; // return name of window 
virtual void display() const; // draw window and contents 


class WindowwWithScrollBars: public Window { 
public: 


virtual void display() const; 


}; 


所 有 Window 对 象 都 有 一 个 名 字 ， 你 能 通过 name 加 ” 数 得 到 它 ， 而 且 所 有 的 窗口 都 可 以 显 
示 ， 你 可 一 个 通过 调用 display KAREN — A. display 为 virtual 的 事实 清楚 地 告诉 你 : 
一 个 纯粹 的 基 类 的 Window 对 象 的 显示 方法 有 可 能 不 同 于 专门 的 WindowWithScrollBars 对 象 


的 显示 方法 (参见 Item 34 和 36) 。 


现在 ， 假 设 你 想 写 一 个 函数 打印 出 一 个 窗口 的 名 字 ， 并 随后 显示 这 个 窗口 。 以 下 这 个 画 数 的 
写法 是 错误 的 : 
void printNameAndDisplay(Window w) // incorrect! parameter 
// may be sliced! 


std::cout << w.name(); 
w.display(); 


考虑 当 你 用 一 个 WindowWithScrollBars 对 象 调 用 这 个 函数 时 会 发 生 什 么 : 


WindowwithScrollBars wwsb; 


printNameAndDisplay(wwsb); 


参数 w 将 被 作为 一 个 Window 对 象 构 造 一 一 它 是 被 传 值 的 ， 记 得 吗 ? 而 且 使 wwsb 表现 得 像 
一 个 WindowWithScrollBars 对 象 的 特殊 信息 都 被 切断 了 。 在 printNameAndDisplay 中 ， 全 然 
不 顾 传递 给 本 数 的 那个 对 象 的 类 型 ，w 将 始终 表现 得 像 一 个 Window 类 的 对 象 〈 因 为 它 就 是 
一 个 Window 类 的 对 象 ) 。 特 别 是 ， 在 printNameAndDisplay 中 调用 display 将 总 是 调用 
Window::display， 绝 不 会 是 WindowWithScrollBars::display。 





绕 过 切断 问题 的 方法 就 是 以 传 引用 给 const 的 方式 传递 w : 


void printNameAndDisplay(const Window& w) // fine, parameter won't 
// be sliced 
std::cout << w.name(); 
w.display(); 


现在 w 将 表现 得 像 实 际 传人 的 那 种 窗口 。 


如 果 你 掀 开 编译 器 的 盖头 偷 看 一 下 ， 你 会 发 现 用 指针 实现 引用 是 非常 典型 的 做 法 ， 所 以 以 引 
用 传递 某 物 实际 上 通常 意味 着 传递 一 个 指针 。 由 此 可 以 得 出 结论 ， 如 果 你 有 一 个 内 建 类 型 的 
对 象 ( 例 如， 一 个 int) ， 以 传 值 方式 传递 它 常常 比 传 引用 方式 更 高 效 。 那 么 ， 对 于 内 建 类 
型 ， 当 你 需要 在 传 值 和 传 引 用 给 const 之 间 做 一 个 选择 时 ， 没 有 道理 不 选择 传 值 。 同 样 的 建 
议 也 适用 于 STL 中 的 迭代 器 (iterators) FESR xt (function objects) ， 因 为 ， 作 为 惯例 ， 
它们 就 是 为 传 值 设 计 的 。 和 迭代 器 (iterators) FIRM (function objects) 的 实现 有 责任 保 
证 拷贝 的 高 效 并 且 不 受 切断 问题 的 影响 。 (这 是 一 个 “规则 如 何 变化 ， 依 赖 于 你 使 用 C++ 的 哪 


一 个 部 分 "的 实例 一 参见 ltem 1。) 





内 建 类 型 很 小 ， 所 以 有 人 就 断定 所 有 的 小 类 型 都 是 传 值 的 上 等 候选 者 ， 即 使 它们 是 用 户 定义 
的 。 这 样 的 推论 是 不 可 靠 的 。 信 仅 因 为 一 个 对 象 小 ， 并 不 意味 着 调用 它 的 拷贝 构造 画 数 就 是 
廉价 的 。 很 多 对 象 一 一 大 多 数 STL 容器 也 在 其 中 一 一 容纳 的 和 指针 一 样 ， 但 是 拷贝 这 样 的 对 
象 必须 同时 拷贝 它们 指向 的 每 一 样 东 西 。 那 可 能 是 非常 昂贵 的 。 


BI 4 — Nt RA SERINE ISR, HS EMERE A — E eR AE a 
和 用 户 定义 类 型 并 不 一 视 同 仁 ， 即 使 他 们 有 同样 的 底层 表示 。 例 如 ， 一 些 编译 器 拒绝 将 仅 由 
一 个 double 组 成 的 对 象 放 入 一 个 寄存 器 中 ， 即 使 在 常规 上 它们 非常 愿意 将 一 个 纯粹 的 double 
放 入 那里 。 如 果 发 生 了 这 种 事情 ， 你 以 传 引 用 方式 传递 这 样 的 对 象 更 好 一 些 ， 因 为 编译 器 理 
所 当然 会 将 一 个 指针 (引用 的 实现 ) MABE. 


小 的 用 户 定义 类 型 不 一 定 是 传 值 的 上 等 候选 者 的 另 一 个 原因 是 : 作为 用 户 定 义 类 型 ， 它 的 大 
小 常常 变化 。 一 个 现在 较 小 的 类 型 在 将 来 版 本 中 可 能 变 得 更 大 ， 因 为 它 的 内 部 实现 可 能 会 变 
化 。 基 至 当 你 换 了 一 个 不 同 的 C++ 实现 时 ， 事 情 都 可 能 会 变化 。 例 如 ， 就 在 我 这 样 写 的 时 
候 ， 一 些 标 准 库 的 string 类 型 的 实现 的 大 小 就 是 另外 一 些 实现 的 七 倍 。 

通常 情况 下 ， 你 能 合理 地 假设 传 值 廉价 的 类 型 仅 有 内 建 类 型 及 STL 中 的 迭代 器 和 辑 数 对 象 类 
型 。 对 其 他 任何 类 型 ， 请 遵循 本 Item 的 建议 ， 并 用 传 引 用 给 const 取代 传 值 。 


Things to Remember 
。 用 传 引用 给 const 取代 传 值 。 典 型 情况 下 它 更 高 效 而 且 可 以 避免 切断 问题 。 


。 这 条 规则 并 不 适用 于 内 建 类 型 及 STL PHAN NBR, MFC, ees 
更 合适 。 


Item 21: 当 你 必须 返回 一 个 对 象 时 不 要 试图 返回 一 
个 引用 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


一 旦 程序 员 抓 住 对 象 传 值 的 效率 隐忧 (参见 ltem 20) ， 很 多 人 就 会 成 为 狂热 的 圣战 分 子 ， 暂 
要 根除 传 值 的 罪恶 ， 无 论 它 隐藏 多 深 。 他 们 不 屈 不 挠 地 追求 传 引用 的 纯度 ， 但 他 们 全 都 犯 了 
一 个 致命 的 错误 : 他 们 开始 传递 并 不 存在 的 对 象 的 引用 。 这 可 不 是 什么 好 事 。 


考虑 一 个 代表 有 理 数 的 类 ， 包 含 一 个 将 两 个 有 理 数 相 乘 的 范 数 : 


class Rational { 


public: 

Rational(int numerator = 0, // see Item 24 for why this 

int denominator = 1); // ctor isn't declared explicit 

private: 

int n, d; // numerator and denominator 
friend 

const Rational // see Item 3 for why the 

operator*(const Rational& lhs, // return type is const 
const Rational& rhs); 

}; 


operator* 的 这 个 版 本 以 传 值 方式 返回 它 的 结果 ， 而 且 如 果 你 没有 担心 那个 对 象 的 构造 和 析 构 
的 代价 ， 你 就 是 在 推卸 你 的 专业 职责 。 如 果 你 不 是 迫不得已 ， 你 不 应 该 为 这 样 的 一 个 对 象 付 
出 成 本 。 所 以 问题 就 在 这 里 : 你 是 迫 不 得 已 吗 ? 


哦 ， 如 果 你 能 用 返回 一 个 引用 来 作为 代替 ， 你 就 不 是 人 迫不得已。 但 是 ， 请 记 住 一 个 引用 仅仅 
是 一 个 名 字 ， 一 个 实际 存在 的 对 象 的 名 字 。 无 论 何 时 只 要 你 看 到 一 个 引用 的 声明 ， 你 应 该 立 
刻 问 自己 它 是 什么 东西 的 另 一 个 名 字 ， 因 为 它 必定 是 某 物 的 另 一 个 名 字 。 在 这 个 operator 的 
情况 下 ， 如 果 画 数 返回 一 个 引用 ， 它 必须 返回 某 个 已 存在 的 而 且 其 中 包含 两 个 对 象 相 乘 的 产 
物 的 Rational 对 象 的 引用 。 


当然 没有 什么 理由 期 望 这 样 一 个 对 象 在 调用 operator 之 前 就 存在 。 也 就 是 说 ， 如 果 你 有 


1/2 
3/5 


Rational a(1, 2); // a 
Rational b(3, 5); // b 


Rational c = a * b; // c should be 3/10 


似乎 没有 理由 期 望 那里 碰巧 已 经 存在 一 个 值 为 十 分 之 三 的 有 理 数 。 不 是 这 样 的 ， 如 果 
operator 返回 这 样 一 个 数 的 引用 ， 它 必须 自己 创建 那个 数字 对 象 。 


一 个 函数 创建 一 个 新 对 象 仅 有 两 种 方法 : 在 栈 上 或 者 在 堆 上 。 栈 上 的 生成 物 通过 定义 一 个 局 
部 变量 而 生成 。 使 用 这 个 策略 ， 你 可 以 用 这 种 方法 试 写 operator : 


const Rational& operator*(const Rational& lhs, // warning! bad code! 
const Rational& rhs) 


Rational result(lhs.n * rhs.n, lhs.d * rhs.d); 
return result; 


(ALIS ARMA, AARNE eRRBAHSNA, Mm result 正 像 任 何其 它 对 象 
一 样 必须 被 构造 。 一 个 更 严重 的 问题 是 这 个 画 数 返回 一 个 引 向 result 的 引用 ， 但 是 result 是 
一 个 局 部 对 象 ， 而 局 部 对 象 在 本 数 退出 时 被 销毁 。 那 么 ， 这 个 operator 的 版 本 不 会 返回 引 向 
一 个 Rational 的 引用 一 一 它 返回 引 向 一 个 前 Rational ; 一 个 便 经 的 Rational ; 一 个 空洞 的 、 
恶臭 的 、 腐 败 的 ， 从 前 是 一 个 Rational 但 永 不 再 是 的 尸体 的 引用 ， 因 为 它 已 经 被 销毁 了 。 任 
何 调用 者 甚至 于 没有 来 得 及 匆匆 看 一 眼 这 个 画 数 的 返回 值 就 立刻 进入 了 未 定义 行为 的 领地 。 
这 是 事实 ， 任 何 返 回 一 个 引 向 局 部 变量 的 引用 的 函数 都 是 错误 的 。 (对 于 任何 返回 一 个 指向 
局 部 变量 的 指针 的 函数 同样 成 立 。) 


那么 ， 让 我 们 考虑 一 下 在 堆 上 构造 一 个 对 象 并 返回 引 向 它 的 引用 的 可 能 性 。 基 于 堆 的 对 象 通 
过 使 用 new 而 开始 存在 ， 所 以 你 可 以 像 这 样 写 一 个 基于 堆 的 operator : 
const Rational& operator*(const Rational& lhs, // warning! more bad 
const Rational& rhs) // code! 


Rational *result = new Rational(lhs.n * rhs.n, lhs.d * rhs.d); 
return *result; 


R, Mc ewmRAetw—T iS Ni KA, AA new 分 配 的 内 存 要 通过 调用 一 个 
适当 的 构造 事 数 进行 初始 化 ， 但 是 现在 你 有 另 一 个 问题 : 谁 是 删除 你 用 new 做 出 来 的 对 象 的 
合适 人 选 ? 


即使 调用 者 尽职 尽责 且 一 心 向 善 ， 它 们 也 不 太 可 能 是 用 这 样 的 方案 来 合理 地 预防 泄漏 : 


Rational w, x, y, Z; 


WES X * y * Z; // same as operator*(operator*(x, y), Z) 


这 里 ， 在 同一 个 语句 中 有 两 个 operator 的 调用 ， 因 此 new 被 使 用 了 两 次 ， 这 两 次 都 需要 使 
用 delete 来 销毁 。 但 是 operator 的 客户 没有 合理 的 办 法 进行 那些 调用 ， 因 为 他 们 没有 合理 的 
办 法 取得 隐藏 在 通过 调用 operator 返回 的 引用 后 面 的 指针 。 这 是 一 个 早已 注定 的 资源 泄漏 。 


但 是 也 许 你 注意 到 无 论 是 在 栈 上 的 还 是 在 堆 上 的 方法 ， 为 了 从 operator 返回 的 每 一 个 
result， 我 们 都 不 得 不 容忍 一 次 构造 画 数 的 调用 。 也 许 你 想起 我 们 最 初 的 目标 是 避免 这 样 的 构 
造 函 数 调 用 。 也 许 你 认为 你 知道 一 种 方法 能 a RAC Aa a 也 许 
下 面 这 个 实现 是 你 做 过 的 ， 一 个 基于 operator 返回 一 个 引 向 static Rational 对 象 的 引用 的 实 
现 ， 而 这 个 static Rational 


const Rational& operator*(const Rational& lhs, // warning! yet more 
const Rational& rhs) // bad code! 
{ 


static Rational result; // static object to which a 
// reference will be returned 


result =... ; // multiply lhs by rhs and put the 
// product inside result 
return result; 


} 


就 像 所 有 使 用 了 static 对 象 的 设计 一 样 ， 这 个 也 会 立即 引起 我 们 的 线程 安全 (thread-safety) 
的 混乱 ， 但 那 是 它 的 比较 明显 的 缺点 。 为 了 看 到 它 的 更 深层 的 缺陷 ， 考 虑 这 个 完全 合理 的 客 
户 代码 : 

bool operator==(const Rational& lhs, // an operator== 

const Rational& rhs); // for Rationals 
Rational a, b, c, d; 
人 
do whatever's appropriate when the products are equal; 


} else { 
do whatever's appropriate when they're not; 
} 


清 猜 会 怎么 样 ?不管 a，b，c，d 的 值 是 什么 ， 表 达 式 ((ab) == (cd)) 总 是 等 于 true ! 


如 果 代 码 重 写 为 功能 完全 等 价 的 另 一 种 形式 ， 这 一 启示 就 很 容易 被 理解 了 : 


if (operator==(operator*(a, b), operator*(c, d))) 


注意 ， 当 operator== 被 调用 时 ， 将 同时 存在 两 个 起 作用 的 对 operato 的 调用 ， 每 一 个 都 将 
返回 引 向 operator* 内 部 的 static Rational 对 象 的 引用 。 因 此 ，operator== 将 被 要 求 比较 
operator* 内 部 的 static Rational 对 象 的 值 和 operator* 内 部 的 static Rational 对 象 的 值 。 如 果 
它们 不 是 永远 相等 ， 那 才 真 的 会 合 人 大 惊 失色 了 。 


这 些 应 该 足够 让 你 信服 试图 从 类 似 operator 这 样 的 函数 中 返回 一 个 引用 纯粹 是 浪费 时 间 ， 但 
是 你 们 中 的 某 些 人 可 能 会 这 样 想 "好 吧 ， 就 算 一 个 static 不 够 用 ， 也 许 一 个 static 的 数组 是 一 


个 窍门 


我 无 法 拿 出 示例 代码 来 肯定 这 个 设计 ， 但 我 可 以 概要 说 明 为 什么 这 个 想法 应 该 让 你 羞愧 得 无 
地 自 容 。 首 先 ， 你 必须 选择 一 个 n 作为 数组 的 大 小 。 如 果 n 太 小 ， 你 可 能 会 用 完 存储 函数 返 
回 值 的 空间 ， 与 刚刚 名 誉 扫地 的 single-static 设计 相 比 ， 在 任何 一 个 方面 你 都 不 会 得 到 更 多 的 
东西 。 但 是 如 果 n 太 大 ， 就 会 降低 你 的 程序 的 性 能 ， 因 为 在 函数 第 一 次 被 调用 的 时 候 数 组 中 
的 每 一 个 对 象 都 会 被 构造 。 即 使 这 个 我 们 正在 讨论 的 男 数 仅 被 调用 了 一 次 ， 也 将 让 你 付出 n 
个 构造 画 数 和 n 个 析 构 函数 的 成 本 。 如 果 “ 优 化 "是 提高 软件 效率 的 过 程 ， 对 于 这 种 东西 也 只 能 
是 “悲观 主义 "的 。 最 后 ， 考 虑 你 怎样 将 你 所 需要 的 值 放 入 数组 的 对 象 中 ， 以 及 你 做 这 些 需 要 付 
出 什么 。 在 两 个 对 象 间 移动 值 的 最 直接 方法 就 是 通过 赋值 ， 但 是 一 次 赋值 将 要 付出 什么 ? 对 
于 很 多 类 型 ， 这 就 大 约 相当 于 调用 一 次 析 构 函数 〈 销 毁 原 来 的 值 ) 加 上 调用 一 次 构造 画 数 
(把 新 值 拷贝 过 去 ) 。 但 是 你 的 目标 是 避免 付出 构造 和 析 构 成 本 ! 面 对 的 结果 就 是 : 这 个 方 
法 绝对 不 会 成 功 。 (不 ， 用 一 个 vector 代替 数组 也 不 会 让 事情 有 多 少 改 进 。) 


写 一 个 必须 返回 一 个 新 对 象 的 函数 的 正确 方法 就 是 让 那个 函数 返回 一 个 新 对 象 。 对 于 
Rational 的 operator*， 这 就 意味 着 下 面 这 些 代 码 或 在 本 质 上 和 与 其 相当 的 某 些 东西 : 


inline const Rational operator*(const Rational& lhs, const Rational& rhs) 


return Rational(lhs.n * rhs.n, lhs.d * rhs.d); 


} 


当然 ， 你 可 能 付出 了 构造 和 析 构 operator 的 返回 值 的 成 本 ， 但 是 从 长 远 看 ， 这 只 是 为 正确 行 
为 付出 的 很 小 的 代价 。 除 此 之 外 ， 这 种 合 你 感到 恐怖 的 账单 也 许 永 远 都 不 会 到 达 。 就 像 所 有 
的 程序 设计 语言 ，C++ 人 允许 编译 器 的 实现 者 在 不 改变 生成 代码 的 可 观察 行为 的 条 件 下 使 用 优 
化 来 提升 它 的 性 能 ， 在 某 些 条 件 下 会 产生 如 下 结果 : operator 的 返回 值 的 构造 和 析 构 能 被 安 
全 地 消除 。 如 果 编 译 器 利用 了 这 一 点 (编译 器 经 常 这 样 做 ) ， 你 的 程序 还 是 在 它 假 定 的 方法 
上 继续 运行 ， 只 是 比 你 期 待 的 要 快 。 


全 部 的 焦点 在 这 里 : 如 果 需 要 在 返回 一 个 引用 和 返回 一 个 对 象 之 间 做 出 决定 ， 你 的 工作 就 是 
让 那个 选择 能 提供 正确 的 行为 。 让 你 的 编译 器 厂商 去 绞 尽 脑汁 使 那个 选择 尽 可 能 地 廉价 。 
Things to Remember 
。 绝 不 要 返回 一 个 局 部 栈 对 象 的 指针 或 引用 ， 绝 不 要 返回 一 个 被 分 配 的 堆 对 象 的 引用 ， 如 
果 存 在 需要 一 个 以 上 这 样 的 对 象 的 可 能 性 时 ， 绝 不 要 返回 一 个 局 部 static 对 象 的 指针 或 引 


用 。 (ltem 4 提供 的 一 个 返回 一 个 局 部 static 的 设计 的 例子 是 合理 的 ， 至 少 在 单线 程 的 
环境 中 是 这 样 。) 


Item 22: 将 数据 成 员 声 明 为 private 
作者 : Scott Meyers 

译 者 : fatalerror99 (iTePub's Nirvana) 

发 布 : http://blog.csdn.net/fatalerror99/ 


好 了 ， 先 公布 一 下 计划 。 首 先 ， 我 们 将 看 看 为 什么 数据 成 员 不 应 该 声明 为 public。 然 后 ， 我 们 
将 看 到 所 有 反对 public 数据 成 员 的 理由 同样 适用 于 protected 数据 成 员 。 这 就 导出 了 数据 成 员 
应 该 是 private 的 结论 ， 至 此 ， 我 们 就 结束 了 。 


那么 ，public 数据 成 员 ， 为 什么 不 呢 ? 


我 们 从 先 从 语法 一 致 性 开始 (参见 Item 18) 。 如 果 数 据 成 员 不 是 public 的 ， 客 户 访问 一 个 对 
象 的 唯一 方法 就 是 通过 成 员 画 数 。 如 果 在 public 接口 中 的 每 件 东 西 都 是 一 个 函数 ， 客 户 就 不 
必 绞 尽 脑 汁 试 图 记 住 当 他 们 要 访问 一 个 类 的 成 员 时 是 否 需 要 使 用 圆 括号 。 他 们 只 要 使 用 就 可 
以 了 ， 因 为 每 件 东西 都 是 一 个 画 数 。 一 生 坚 持 这 一 方针 ， 能 节省 很 多 挠 头 的 时 间 。 


但 是 也 许 你 不 认为 一 致 性 的 理由 是 强制 性 的 。 使 用 函数 可 以 让 你 更 加 精确 地 控制 成 员 的 可 存 
取 性 的 事实 又 怎么 样 呢 ? 如果 你 让 一 个 数据 成 员 为 public， 每 一 个 人 都 可 以 读 写 访 问 它 ， 但 是 
如 果 你 使 用 画 数 去 得 到 和 设置 它 的 值 ， 你 就 能 实现 橙 止 访问 ， 只 读 访 问 和 读 写 访问 。 嘿 嘿 ， 
如 果 你 需要 ， 你 其 至 可 以 实现 只 写 访问 : 


class AccessLevels { 
public: 


int getReadOnly() const { return readOnly; } 
void setReadWrite(int value) { readwrite = value; } 
int getReadWrite() const { return readwrite; } 
void setwWriteOnly(int value) { writeOnly = value; } 
private: 
int noAccess; // no access to this int 
int readOnly; // read-only access to this int 
int readwrite; // read-write access to this int 
int writeOnly; // write-only access to this int 


这 种 条 分 线 析 的 访问 控制 很 重要 ， 因 为 多 数 数 据 成 员 需 要 被 隐藏 。 每 一 个 数据 成 员 都 需要 一 
+ getter 和 setter 的 情况 是 很 罕见 的 。 

还 不 相信 吗 ? 那么 该 拿 出 一 门 重炮 了 : 封装 。 如 果 你 通过 一 个 画 数 实现 对 数据 成 员 的 访问 ， 
你 可 以 在 以 后 用 一 个 计算 来 替换 这 个 数据 成 员 ， 使 用 你 的 类 的 人 不 会 有 任何 察觉 。 


例如 ， 假 设 你 为 一 个 监视 通过 的 汽车 的 速度 的 自动 设备 写 一 个 应 用 程序 。 每 通过 一 辆 汽车 ， 
它 的 速度 就 被 计算 ， 而 且 那 个 值 要 加 入 到 迄今 为 止 收 集 到 的 所 有 速度 数据 的 集合 中 : 


class SpeedDataCollection { 


public: 
void addValue(int speed); // add a new data value 
double averageSoFar() const; // return average speed 
J; 


MEŽ EM AKA averageSoFar 的 实现 : 实现 它 的 办 法 之 一 是 在 类 中 用 一 个 数据 成 员 来 实时 
变化 迄今 为 止 收 集 到 的 所 有 速度 数据 的 平均 值 。 无 论 何 时 averageSoFar 被 调用 ， 它 只 是 返回 
那个 数据 成 员 的 值 。 另 一 个 不 同 的 方法 是 在 每 次 调用 averageSoFar 时 重新 计算 它 的 值 ， 通 过 
分 析 集 合 中 每 一 个 数据 值 它 能 做 成 这 些 事情 。 


第 一 种 方法 〈 保 持 一 个 实时 变化 的 值 ) 使 每 一 个 SpeedDataCollection 对 象 都 比较 大 ， 因 为 
你 必须 为 持 有 实时 变化 的 平均 值 ， 累 计 的 和 以 及 数据 点 的 数量 分 配 空 间 。 可 是 ， 
averageSoFar 能 实现 得 非常 高 效 ， 它 仅仅 是 一 个 返回 实时 变化 的 平均 值 的 inline RR (参见 
Item 30) 。 反 过 来 ， 无 论 何 时 被 请 求 都 要 计算 平均 值 使 得 averageSoFar 的 运行 比较 慢 ， 但 
是 每 一 个 SpeedDataCollection 对 象 都 比较 小 。 


谁 能 说 哪 一 个 最 好 ? 在 内 存 非常 紧张 的 机 器 (例如 ， 一 个 谋 入 式 道 旁 设 备 ) 上 ， 以 及 在 一 个 
很 少 需要 平均 值 的 应 用 程序 中 ， 每 次 都 计算 平均 值 可 能 是 较 好 的 解决 方案 。 在 一 个 频繁 需要 
平均 值 的 应 用 程序 中 ， 速 度 是 基本 的 要 求 ， 而 且 内 存 不 成 问题 ， 保 持 一 个 实时 变化 的 平均 值 
更 为 可 取 。 这 里 的 重点 在 于 通过 经 由 一 个 成 员 图 数 访 问 平 均值 (也 就 是 说 ， 通 过 将 它 封 
装 ) ， 你 能 互 换 这 两 个 不 同 的 实现 (也 包括 其 他 你 可 能 想到 的 ) ， 对 于 客户 ， 最 多 也 就 是 必 
须 重 新 编译 。 (你 可 以 用 在 后 面 的 ltem 31 中 记述 的 技术 来 消除 这 个 麻烦 。) 


将 数据 成 员 隐 藏 在 功能 性 的 接口 之 后 能 为 各 种 实现 提供 弹性 。 例 如 ， 它 可 以 在 读 或 者 写 的 时 
候 很 简单 地 通报 其 他 对 象 ， 可 以 检验 类 的 不 变量 以 及 本 数 的 前 置 或 后 置 条 件 ， 可 以 在 多 线程 
环境 中 执行 同步 任务 ， 等 等 。 从 类 似 Delphi 和 C# 的 语言 来 到 C++ 的 程序 员 会 认同 这 种 类 似 
那些 语言 中 的 “属性 "的 等 价 物 的 功能 ， 虽 然 需 要 附加 一 个 带 圆 括号 的 额外 的 set。 


关于 封装 的 要 点 可 能 比 它 最 初 显现 出 来 的 更 加 重要 。 如 果 你 对 你 的 客户 隐藏 你 的 数据 成 员 
(也 就 是 说 ， 封 装 它 们 ) ， 你 就 能 确保 类 的 不 变量 总 能 被 维持 ， 因 为 只 有 成 员 孙 数 能 影响 它 
们 。 此 外 ， 你 预 留 了 以 后 改变 你 的 实现 决策 的 权力 。 如 果 你 不 隐藏 这 样 的 决策 ， 你 将 很 快 发 
现 ， 即 使 你 拥有 一 个 类 的 源 代码 ， 你 改变 任何 一 个 public 的 东西 的 能 力也 是 非常 有 限 的 ， 因 
为 有 太 多 的 客户 代码 将 被 破坏 。public 意味 着 没有 封装 ， 而 且 几 乎 可 以 说 ， 没 有 封装 意味 着 不 
可 改变 ， 尤 其 是 被 广泛 使 用 的 类 。 但 是 仍然 被 广泛 使 用 的 类 大 多 数 都 是 需要 封装 的 ， 因 为 它 
们 可 以 从 用 一 种 更 好 的 实现 蔡 换 现 有 实现 的 能 力 中 获得 最 多 的 益处 。 


反对 protected 数据 成 员 的 理由 是 类 似 的 。 实 际 上 ， 它 是 一 样 的 ， 虽 然 起 先 看 起 来 似乎 不 那么 
清楚 。 关 于 语法 一 致 性 和 条 分 缕 析 的 访问 控制 的 论证 就 像 用 于 public 一 样 可 以 应 用 于 
protected， 但 是 关于 封装 又 如 何 呢 ? 难道 protected 数据 成 员 不 比 public 数据 成 员 更 具有 封 
装 性 吗 ? 实话 实说 ， 合 人 惊讶 的 答案 是 它们 不 。 


Item 23 解释 了 如 果 某 物 发 生 了 变化 ， 某 物 的 封装 与 可 能 被 破坏 的 代码 数量 成 反比 。 于 是 ， 如 
果 数 据 成 员 发 生 了 变化 例如， 如果 它 被 从 类 中 移 除 (可 能 是 为 了 替换 为 计算 ， 就 像 在 上 面 
的 averageSoFar 中 ) ) ， 数 据 成 员 的 封装 性 与 可 能 被 破坏 的 代码 数量 成 反比 。 


假设 我 们 有 一 个 public 数据 成 员 ， 随 后 我 们 消除 了 它 。 有 多 少 代码 会 被 破坏 呢 ? 所 有 使 用 了 
它 的 客户 代码 ， 其 数量 通常 大 得 难以 置信 。 从 而 public 数据 成 员 就 是 完全 未 封装 的 。 但 是 ， 
假设 我 们 有 一 个 protected 数据 成 员 ， 随 后 我 们 消除 了 它 。 现 在 有 多 少 代码 会 被 破坏 呢 ? 所 有 
使 用 了 它 的 派生 类 ， 典 型 情况 下 ， 代 码 的 数量 还 是 大 得 难以 置信 。 从 而 protected 数据 成 员 就 
像 public 数据 成 员 一 样 没有 封装 ， 因 为 在 这 两 种 情况 下 ， 如 果 数 据 成 员 发 生变 化 ， 被 破坏 的 
客户 代码 的 数量 都 大 得 难以 置信 。 这 并 不 符合 直觉 ， 但 是 富有 经 验 的 库 实 现 者 会 告诉 你 ， 这 
是 千 真 万 确 的 。 一 旦 你 声明 一 个 数据 成 员 为 public 或 protected， 而 且 客 户 开 始 使 用 它 ， 就 很 
难 再 改变 与 这 个 数据 成 员 有 关 的 任何 事情 。 有 太 多 的 代码 不 得 不 被 重 写 ， 重 测试 ， 重 文档 
化 ， 或 重 编译 。 从 封装 的 观点 来 看 ， 实 际 只 有 两 个 访问 层次 : private (提供 了 封装 ) 与 所 有 
例外 (没有 提供 封装 ) 。 


Things to Remember 


声明 数据 成 员 为 private。 它 为 客户 提供 了 访问 数据 的 语法 层 上 的 一 致 ， 提 供 条 分 缕 析 的 访问 
控制 ， 人 允许 不 变量 被 强制 ， 而 且 为 类 的 作者 提供 了 实现 上 的 弹性 。 


protected 并 不 比 public 的 封装 性 强 。 


Item 23: HJER A FER THIER EX A aX 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


想象 一 个 象征 web 浏览 器 的 类 。 在 大 量 的 函数 中 ， 这 样 一 个 类 也 许 会 提供 清空 已 下 载 成 分 的 
缓存 。 清 空 已 访问 URLs 的 历史 ， 以 及 从 系统 移 除 所 有 cookies 的 功能 : 


class WebBrowser { 
public: 


void clearCache(); 
void clearHistory(); 
void removeCookies(); 


me 


很 多 用 户 希望 能 一 起 执行 全 部 这 些 动作 ， 所 以 WebBrowser 可 能 也 会 提供 一 个 函数 去 这 样 
做 : 


class WebBrowser { 
public: 


void clearEverything(); // calls clearCache, clearHistory, 
// and removeCookies 


Ta 


SRK, MPRA IE A A Ae SA A RRE 


void clearBrowser(WebBrowser& wb) 


{ 


wb.clearCache(); 
wb.clearHistory(); 
wb. removeCookies(); 


} 


那么 哪个 更 好 呢 ， 成 员 画 数 clearEverything 2 EJF A BŽ clearBrowser ? 


面 性 对 象 原则 指出 : eae 它们 进行 操作 的 函数 应 该 被 绑 定 到 一 起 ， o HAE 
更 好 的 选择 。 不 幸 的 是 ， 这 个 建议 是 不 正确 的 。 它 产生 于 对 面向 对 象 是 什么 的 一 个 误解 。 面 
向 对 象 原 则 指出 数据 应 该 尽 可 能 被 封装 。 与 直觉 不 同 ， 成 员 画 数 clearEverything 造成 
ELJER A IŽ clearBrowser 更 差 的 封装 性 。 此 外 ， 提 供 非 成 员 画 数 人 允许 WebBrowser 相关 功 
能 的 更 大 的 包装 弹性 ， 而 且 ， 可 以 获得 更 少 的 编译 依赖 和 WebBrowser 扩展 性 的 增进 。 
而 ， 在 很 多 方面 非 成 员 方 法 比 一 个 成 员 函 数 更 好 。 理 解 它 的 原因 是 非常 重要 的 。 


我 们 将 从 封装 开始 。 如 果 某 物 被 封装 ， 它 被 从 视线 中 隐藏 。 越 多 的 东西 被 封装 ， 就 越 少 有 未 
西 能 看 见 它 。 越 少 有 东西 能 看 见 它 ， 我 们 改变 它 的 弹性 就 越 大 ， 因 为 我 们 的 改变 仅仅 直接 影 
响 那 些 能 看 见 我 们 变 了 什么 的 东西 。 某 物 的 封装 性 越 强 ， 那 么 我 们 改变 它 的 能 力 就 越 强 。 这 就 
是 将 封装 的 价值 评价 为 第 一 的 原因 : 它 为 我 们 提供 一 种 改变 事情 的 弹性 ， 而 仅仅 影响 有 限 的 
客户 。 

结合 一 个 对 象 考虑 数据 。 越 少 有 代码 能 看 到 数据 (也 就 是 说 ， 访 问 它 ) ， 数 据 封装 性 就 越 
强 ， 我 们 改变 对 象 的 数据 的 特性 的 自由 也 就 越 大 ， 上 比如 ， 数 据 成 员 的 数量 ， 它 们 的 类 型 ， 等 
等 。 作 为 多 少 代码 能 看 到 一 块 数据 的 粗糙 的 尺度 ， 我 们 可 以 计数 能 访问 那 块 数据 的 范 数 的 数 
量 : 越 多 男 数 能 访问 它 ， 数 据 的 封装 性 就 越 弱 。 


Item 22 说 明了 数据 成 员 应 该 是 private 的 ， 因 为 如 果 它 们 不 是 ， 就 有 无 限量 的 函数 能 访问 它 
们 。 它 们 根本 就 没有 封装 。 对 于 private 数据 成 员 ， 能 访问 他 们 的 函数 的 数量 就 是 类 的 成 员 画 
数 的 数量 加 上 友 元 函数 的 数量 ， 因 为 只 有 成 员 和 友 元 能 访问 private 成 员 。 假 设 在 一 个 成 员 范 
数 (能 访问 的 不 只 是 一 个 类 的 private 数据 ， 还 有 private HA, MÆ, typedefs, SS) 和 一 
个 提供 同样 功能 的 非 成 员 非 友 元 函数 〈 不 能 访问 上 述 那 些 示 西 ) 之 间 有 一 个 选择 ， 能 获得 更 

强 封装 性 的 选择 是 非 成 员 非 友 元 函数 ， 因 为 它 不 会 增加 能 访问 类 的 private 部 分 的 函数 的 数 

量 。 这 就 解释 了 为 什么 clearBrowser ( 非 成 员 非 友 元 函数 ) 比 clearEverything (AK A ENR) 

更 可 取 : 它 能 为 WebBrowser 获得 更 强 的 封装 性 。 


在 这 一 点 ， 有 两 件 事 值 得 注意 。 首 先 ， 这 个 论证 只 适用 于 非 成 员 非 友 元 函数 。 友 元 能 像 成 员 
函数 一 样 访问 一 个 类 的 private 成 员 ， 因 此 同样 影响 封装 。 从 封装 的 观点 看 ， 选 择 不 是 在 成 员 
和 非 成 员 辑 数 之 间 ， 而 是 在 成 员 函 数 和 非 成 员 非 友 元 函数 之 间 。 (当然 ， 封 装 并 不 是 仅 有 的 
观点 ，ltem 24 说 明 如 果 观 点 来 自 隐 式 类 型 转换 ， 选 择 就 是 在 成 员 和 非 成 员 画 数 之 间 。) 


需要 注意 的 第 二 件 事 是 ， 如 果 仅 仅 是 为 了 关注 封装 ， 则 可 以 指出 ， 一 个 函数 是 一 个 类 的 非 成 
员 并 不 意味 着 它 不 可 以 是 另 一 个 类 的 成 员 。 这 对 于 习惯 了 所 有 回 数 必须 属于 类 的 语言 ( 例 
如 ，Eiffel，Java，C#， 等 等 ) 的 程序 员 是 一 个 适度 的 安奈 。 例 如， 我 们 可 以 使 clearBrowser 
成 为 一 个 utility 类 的 static KARR. RBC ARE WebBrowser 的 一 部 分 (或 友 元 ) ， 它 就 
会 影响 WebBrowser 的 private 成 员 的 封装 。 


在 C++ 中 ， 一 个 更 自然 的 方法 是 使 clearBrowser 成 为 与 WebBrowser 在 同一 个 
namespace (名 字 空 间 ) PRIJE A RIŽ : 


namespace WebBrowserStuff { 
class WebBrowser { ... }; 


void clearBrowser(WebBrowser& wb); 


相对 于 形式 上 的 自然 ， 这 样 更 适用 于 它 。 无 论 如 何 ， 因 为 名 字 空 间 (不 像 类 ) 能 展开 到 多 个 
源 文件 中 。 这 是 很 重要 的 ， 因 为 类 似 clearBrowser 的 函数 是 方便 性 函数 。 作 为 既 不 是 成 员 也 
不 是 友 元 ， 他 们 没有 对 WebBrowser 进行 专门 的 访问 ， 所 以 他 们 不 能 提供 任何 一 种 


WebBrowser 的 客户 不 能 通过 其 它 方 法 得 到 的 功能 。 例 如 ， 如 果 clearBrowser 不 存在 ， 客 户 
可 以 直接 调用 clearCache， ala ll 和 removeCookies 本 身 。 


一 个 类 似 WebBrowser 的 类 可 以 有 大 量 的 方便 性 函数 ， 一 些 是 书签 相关 的 ， 另 一 些 打印 相关 
的 ， 还 有 一 些 是 cookie 管理 相关 的 ， 等 等 。 作 为 一 个 一 般 的 惯例 ， 多 数 客户 仅 对 这 些 方 便 性 
本 数 的 集合 中 的 一 些 感 兴趣 。 没 有 理由 让 一 个 只 对 书签 相关 的 方便 性 函数 感 兴趣 的 客户 在 编 
译 时 依赖 其 它 范 数 ， 例 如 ，cookie 相关 的 方便 性 函数 。 分 隔 它 们 的 直截了当 的 方法 就 是 在 一 
个 头 文件 中 声明 书签 相关 的 方便 性 函数 ， 在 另 一 个 不 同 的 头 文件 中 声明 cookie 相关 的 方便 性 
函数 ， 在 第 三 个 头 文件 声明 打印 相关 的 方便 性 函数 ， 等 等 : 


// header "webbrowser.h" — header for class WebBrowser itself 
// as well as "core" WebBrowser-related functionality 
namespace WebBrowserStuff { 


class WebBrowser { ... }; 


// "core" related functionality, e.g. 
// non-member functions almost 
// all clients need 


// header "webbrowserbookmarks.h" 
namespace WebBrowserStuff { 

Pies // bookmark-related convenience 
// functions 
// header "webbrowsercookies.h" 
namespace WebBrowserStuff { 

Pre // cookie-related convenience 
} // functions 


注意 这 里 就 像 标 准 C++ 库 组 织 得 一 样 严密 。 胜 于 有 一 个 单独 的 一 体式 的 

<C++StandardLibrary> 头 文件 包含 std namespace 中 的 所 有 东西 ， 它 们 在 许多 头 文件 中 ( 例 

如 ，<vector>，<algorithm>，<memory>， 等 等 ) ， 每 一 个 都 声明 了 std 中 的 一 些 机 能 。 仅 仅 

需要 vector 相关 机 能 的 客户 不 需要 #include <memory>, FA list 的 客户 没有 必要 #include 

<list>。 这 就 允许 客户 在 编译 时 仅仅 依赖 他 们 实际 使 用 的 那 部 分 系统 。 (参见 Item 31 对 减少 

编译 依赖 的 其 它 方法 的 讨论 。) 当 机 能 来 自 一 个 类 的 成 员 函 数 时 ， 用 这 种 方法 分 割 它 是 不 可 
能 的 ， 因 为 一 个 类 必须 作为 一 个 整体 来 定义 ， 它 不 能 四 分 五 裂 。 


将 所 有 方便 性 函数 放 和 人 多 个 头 文件 中 一 但 是 在 一 个 namespace 中 一 一 也 意味 着 客户 能 容易 

地 扩充 方便 性 函数 的 集合 。 他 们 必须 做 的 全 部 就 是 在 namespace 中 加 入 更 多 的 非 成 员 非 友 元 
函数 。 例 如 ， 如 果 一 个 WebBrowser 的 客户 决定 写 一 个 关于 下 载 图 像 的 方便 性 函数 ， 他 或 她 
仅仅 需要 新 建 一 个 头 文件 ， 包 含 那 些 函 数 在 WebBrowserStuff namespace 中 的 声明 。 这 个 新 
的 函数 现在 就 像 其 它 方便 性 函数 一 样 可 用 并 被 集成 。 这 是 类 不 能 提供 的 另 一 个 特性 ， 因 为 类 

定义 对 于 客户 是 扩充 封闭 的 。 当 然 ， 客 户 可 以 派生 新 类 ， 但 是 派生 类 不 能 访问 基 类 中 被 封装 

的 (也 就 是 说 ，private 的 ) 成 员 ， 所 以 这 样 的 “扩充 机 能 "只 有 二 等 身份 。 此 外 ， 就 像 Item 7 

中 解释 的 ， 不 是 所 有 的 类 都 是 作为 基 类 设计 的 。 


Things to Remember 


。 HFR AFRICA MATS, RTE, MALEN Ft 
性 。 


Item 24: 当 类 型 转换 应 该 用 于 所 有 参 效 时 ， 声 明 为 
非 成 员 函 数 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


在 此 书 的 Introduction 中 我 谈 到 让 一 个 类 支持 隐 式 类 型 转换 通常 是 一 个 不 好 的 主意 。 当 然 ， 这 
条 规则 有 一 些 例外 ， 最 普通 的 一 种 就 是 在 创建 数值 类 型 时 。 例 如 ， 如 果 你 设计 一 个 用 来 表现 
有 理 数 的 类 ， 人 允许 从 整数 到 有 理 数 的 隐 式 转换 看 上 去 并 非 不 合理 。 这 的 确 不 比 C++ 的 内 建 类 
型 从 int 到 double 的 转换 更 不 合理 (而 且 比 C++ 的 内 建 类 型 从 double 到 int 的 转换 合理 得 
多 ) 。 在 这 种 情况 下 ， 你 可 以 用 这 种 方法 开始 你 的 Rational 类 : 


class Rational { 
public: 
Rational(int numerator = 0, // ctor is deliberately not explicit; 
int denominator = 1); // allows implicit int-to-Rational 
// conversions 


int numerator() const; // accessors for numerator and 
int denominator() const; // denominator — see Item 22 
private: 


rad 


你 知道 你 应 该 支持 算术 运算 ， 比 如 加 法 ， 乘 法 ， 等 等 ， a PA, FF 
成 员 画 数 ， 还 是 非 成 员 的 友 元 函数 来 实现 它们 。 你 的 直觉 告诉 你 ， 当 你 摇摆 不 定 的 时 候 ， 你 
应 该 坚持 面向 对 象 的 原则 。 你 了 解 这 一 点 ， 于 是 断定 ， pa RRRAERE Rational 类 相 
关 ， 所 以 在 Rational 类 的 内 部 实现 有 理 数 的 operato 似乎 更 加 正常 。 但 是 ， 与 直觉 不 符 的 

是 ，ltem 23 指出 将 函数 放 在 它们 所 关联 的 类 的 内 部 的 主张 有 时 候 和 与 面向 对 象 的 原则 正好 相 
反 ， 但 是 让 我 们 将 它 先 放 到 一 边 ， 来 研究 一 下 让 operator* 成 为 Rational 的 一 个 成 员 画 数 的 想 
法 究竟 如 何 : 

class Rational { 

public: 


const Rational operator*(const Rational& rhs) const; 


(如 果 你 不 能 确定 为 什么 这 个 范 数 声明 为 这 个 样子 一 一 返回 一 个 const by-value 的 结果 ， 却 
持 有 一 个 reference-to-const 作为 它 的 参数 请 参考 ltem 3，20 和 21。) 





这 个 设计 让 你 在 有 理 数 相 乘 时 不 费 吹 灰 之 力 : 


Rational oneEighth(1, 8); 
Rational oneHalf(1, 2); 


Rational result = oneHalf * oneEighth; // fine 


result = result * oneEighth; // fine 


但 是 你 并 不 感到 满意 。 你 还 希望 支持 混合 模式 的 操作 ， 以 便 让 Rationals 能 够 和 其 它 类 型 〈 例 
如 ，int) 相 乘 。 毕竟 ， 很 少 有 事情 像 两 个 数 相 乘 那么 正常 ， 即 使 它们 碰巧 是 数字 的 不 同类 
型 。 


当 你 试图 做 混合 模式 的 算术 运算 时 ， 可 是 ， 你 发 现 只 有 一 半 时 间 它 能 工作 : 


result = oneHalf * 2; // fine 


result = 2 * oneHalf; // error! 


这 是 一 个 不 好 的 征兆 。 乘 法 必须 是 可 交换 的 ， 记 得 吗 ? 
当 你 重 写 最 后 两 个 例子 为 功能 等 价 的 另 一 种 形式 时 ， 问 题 的 来 源 就 变 得 很 明显 了 : 


result = oneHalf.operator*(2); // fine 


result = 2.operator*(oneHalf); // error! 


xt & oneHalf 是 一 个 包含 operator XEK, Prose AARN NR, Aim, BR2S 
类 没有 关系 ， 因 而 没有 operator KAW. witsalel eS SF RREA Rig EIJER A BY 
operator*s (也 就 是 说 ， 在 namespace 或 全 局 范围 内 的 operator*s) 


result = operator*(2, oneHalf); // error! 


但 是 在 本 例 中 ， 没 有 非 成 员 的 持 有 一 个 int 和 一 个 Rational 的 operator*， 所 以 搜索 失败 。 


再 看 一 眼 那 个 成 功 的 调用 。 你 会 发 现 它 的 第 二 个 参数 是 整数 2， 然 而 Rational::operator 却 持 
有 一 个 Rational 对 象 作为 它 的 参数 。 这 里 发 生 了 什么 呢 ? 为 什么 2 在 一 个 位 置 能 工作 ， 在 其 
它 地 方 却 不 行 呢 ? 


发 生 的 是 隐 式 类 型 转换 。 编 译 器 知道 你 传递 一 个 int 而 那个 函数 需要 一 个 Rational， 但 是 它们 
也 知道 通过 用 你 提供 的 int 调用 Rational 的 构造 画 数 ， 它 们 能 做 出 一 个 相配 的 Rational， 这 就 
是 它们 的 所 作 所 为 。 换 句 话说， 它们 将 那个 调用 或 多 或 少 看 成 如 下 这 样 : 
const Rational temp(2); // create a temporary 
// Rational object from 2 


result = oneHalf * temp; // same as oneHalf.operator*(temp); 


当然 ， 二 一 个 非 显 性 的 构造 本 数 。 如 果 Rational His BE 
显 性 的 ， 这 些 语句 都 将 无 法 编译 : 
result = oneHalf * 2; // error! (with explicit ctor); 
// can't convert 2 to Rational 


result = 2 * oneHalf; // same error, same problem 


支持 混合 模式 操作 失败 了 ， 但 是 至 少 两 个 语句 的 行为 将 步调 一 致 。 


然而 ， 你 的 目标 是 既 保 持 一 致 性 又 要 支持 混合 运算 ， 也 就 是 说 ， 一 个 能 使 上 面 两 个 语句 都 可 
以 编译 的 设计 。 让 我 们 返回 这 两 个 语句 看 一 看 ， 为 什么 即使 Rational 的 构造 函数 不 是 显 式 
的 ， 也 是 一 个 可 以 编译 而 另 一 个 不 行 : 


result = oneHalf * 2; // fine (with non-explicit ctor) 


result = 2 * oneHalf; // error! (even with non-explicit ctor) 


其 原因 在 于 仅仅 当 参 数列 在 参数 列表 中 的 时 候 ， 它 们 才 有 资格 进行 隐 式 类 型 转换 。 而 对 应 于 
成 员 画 数 被 调用 的 那个 对 象 的 隐 含 参数 一 一 this 指针 指向 的 那个 一 一 根本 没有 资格 进行 隐 式 
转换 。 这 就 是 为 什么 第 一 个 调用 能 编译 而 第 二 个 不 能 。 第 一 种 情况 包括 一 个 参数 被 列 在 参数 
列表 中 ， 而 第 二 种 情况 没有 。 


你 还 是 希望 支持 混合 运算 ， 然 而 ， 现 在 做 到 这 一 点 的 方法 或 许 很 清楚 了 : 让 operator* 作为 非 
成 员 画 数 ， 因 此 就 允许 便 一 起 将 隐 式 类 型 转换 应 用 于 所 有 参数 : 


class Rational { 


// contains no operator* 


J; 

const Rational operator*(const Rational& lhs, // now a non-member 
const Rational& rhs) // function 

{ 


return Rational(lhs.numerator() * rhs.numerator(), 
lhs.denominator() * rhs.denominator()); 


Rational oneFourth(1, 4); 
Rational result; 


oneFourth * 2; // fine 
2 * oneFourth; // hooray, it works! 


result 
result 


这 样 的 确 使 故事 有 了 一 个 圆满 的 结局 ， 但 是 有 一 个 吹 毛 求 疲 的 毛病 。operator 应 该 不 应 该 作 
为 Rational 类 的 友 元 呢 ? 


在 这 种 情况 下 ， 答 案 是 不 ， 因 为 operator 能 够 根据 Rational 的 public 接口 完全 实现 。 上 面 
的 代码 展示 了 做 这 件 事 的 方法 之 一 。 这 导出 了 一 条 重要 的 结论 : 与 成 员 函 数 相 对 的 是 非 成 员 
郴 数 ， 而 不 是 友 元 函数 。 太 多 的 程序 员 假 设 如 果 一 个 函数 与 一 个 类 有 关 而 又 不 应 该 作为 成 员 
时 (例如 ， 因 为 所 有 的 参数 都 需要 类 型 转换 ) ， 它 应 该 作为 友 元 。 这 个 示例 证 明 这 样 的 推理 


是 有 缺陷 的 。 无 论 何 时 ， 只 有 你 能 避免 友 元 函数 ， 你 就 避免 它 ， 因 为 ， 就 像 在 现实 生活 中 ， 
朋友 的 麻烦 通常 多 于 他 们 的 价值 。 当 然 ， 有 时 友谊 是 正当 的 ， 但 是 事实 表明 仅仅 因为 画 数 不 
应 该 作为 成 员 并 不 自动 意味 着 它 应 该 作为 友 元 。 

本 ltem 包含 真理 ， 除 了 真理 一 无 所 有 ， 但 它 还 不 是 完整 的 真理 。 当 你 从 Object-Oriented 

C++ 穿 过 界线 进入 Template C++ (参见 ltem 1) 而 且 将 Rational 做 成 一 个 类 模板 代 蔡 一 个 
类 ， 就 有 新 的 问题 要 考虑 ， 也 有 新 的 方法 来 解决 它们 ， 以 及 一 些 合 人 惊讶 的 设计 含义 。 这 样 
的 问题 ， 解 决 方法 和 含义 是 ltem 46 的 主题 。 

Things to Remember 


。 如 果 你 需要 在 一 个 事 数 的 所 有 参数 (包括 被 this 指针 所 指向 的 那个 ) 上 使 用 类 型 转换 ， 
这 个 函数 必须 是 一 个 非 成 员 。 


Item 25: 考虑 支持 不 抛 异 常 的 swap 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


swap 是 一 个 有 趣 的 函数 。 最 早 作为 STL 的 一 部 分 被 引入 ， 后 来 它 成 为 异常 安全 编程 
(exception-safe programming) 的 支柱 (参见 Item 29) 和 压制 自 赋值 可 能 性 的 通用 机 制 
(参见 Item 11) 。 因 为 swap 太 有 用 了 ， 所 以 正确 地 实现 它 非常 重要 ， 但 是 伴随 它 的 不 同 寻 
常 的 重要 性 而 来 的 ， 是 一 系列 不 同 寻常 的 复杂 性 。 在 本 ltem 中 ， 我 们 就 来 研究 一 下 这 些 复杂 
性 究竟 是 什么 样 的 以 及 如 何 对 付 它们 。 


交换 两 个 对 象 的 值 就 是 互相 把 自己 的 值 送 给 对 方 。 缺 省 情况 下 ， 通 过 标准 的 交换 算法 来 实现 
交换 是 非常 成 熟 的 技术 。 典 型 的 实现 完全 符合 你 的 预期 : 


namespace std { 


template<typename T> // typical implementation of std::swap; 
void swap(T& a, T& b) // swaps a's and b's values 

T temp(a); 

a = b; 

b = temp; 
} 


只 要 你 的 类 型 支持 拷贝 GEN HINA AeA) ， 缺 省 的 swap 实现 就 能 交换 
你 的 类 型 的 对 象 ， 而 不 需要 你 做 任何 特别 的 支持 工作 


可 是 ， 缺 省 的 swap 实现 可 能 不 那么 酷 。 它 涉及 三 个 对 象 的 拷贝 : 从 a 到 temp， 从 b Za, 
以 及 从 temp 到 b。 对 一 些 类 型 来 说 ， 这 些 副本 全 是 不 必要 的 。 对 于 这 样 的 类 型 ， 缺 省 的 
swap 就 好 像 让 你 坐 着 快车 驶 入 小 巷 。 

这 样 的 类 型 中 最 重要 的 就 是 那些 主要 由 一 个 指针 组 成 的 类 型 ， 那 个 指针 指向 包含 真正 数据 的 
另 一 种 类 型 。 这 种 设计 方法 的 一 种 常见 的 表现 形式 是 "pimpl idiom" ("pointer to 

参见 Item 31) 。 一 个 使 用 了 这 种 设计 的 Widget 类 可 能 就 像 这 样 : 





implementation" 


class WidgetImpl { // class for Widget data; 


public: // details are unimportant 
private: 
int a, b, O // possibly lots of data — 
std::vector<double> v; // expensive to copy! 
}; 
class Widget { // class using the pimpl idiom 
public: 


Widget(const Widget& rhs); 


Widget& operator=(const Widget& rhs) // to copy a Widget, copy its 
// WidgetImpl object. For 
bid // details on implementing 
*pImpl = *(rhs.pImpl); // operator= in general, 
NE // see Items 10, 11, and 12. 
} 


private: 
WidgetImpl *pImpl; // ptr to object with this 


1 


为 了 交换 这 两 个 Widget 对 象 的 值 ， 我 们 实际 要 做 的 就 是 交换 它们 的 plmpl 指针 ， 但 是 缺 省 的 
交换 算法 没有 办 法 知道 这 些 。 它 不 仅 要 拷贝 三 个 Widgets， 而 且 还 有 三 个 Widgetlmpl 对 象 ， 
效率 太 低 了 。 一 点 都 不 酷 。 


当 交 换 Widgets 的 是 时 候 ， 我 们 应 该 告诉 std::swap 我 们 打算 做 什么 ， 执 行 交 换 的 方法 就 是 
交换 它们 内 部 的 plmpl 指针 。 这 种 方法 的 正规 说 法 是 : 针对 Widget 特 化 

std::swap (specialize std::swap for Widget) 。 下 面 是 一 个 基本 的 想法 ， 虽 然 在 这 种 形式 下 它 
还 不 能 通过 编译 : 


namespace std { 


template<> // this is a specialized version 
void swap<wWidget>(Widget& a, // of std::swap for when T is 
Widget& b) // Widget; this won't compile 
{ 
swap(a.pImpl, b.pImpl); // to swap Widgets, just swap 


// their pImpl pointers 


这 个 函数 开头 的 "template<>" 表明 这 是 一 个 针对 std::swap 的 完全 模板 特 化 (total template 
specialization) ( 某 些 书 中 称 为 "full template specialization" 或 "complete template 
specialization" 译 者 注 ) ， 辑 数 名 后 面 的 "<Widget>" 表明 特 化 是 在 T 为 Widget 类 型 时 
发 生 的 。 换 句 话 说 ， 当 通用 的 swap 模板 用 于 Widgets 时 ， 就 应 该 使 用 这 个 实现 。 通 常 ， 我 
们 改变 std namespace 中 的 内 容 是 不 被 允许 的 ， 但 允许 为 我 们 自己 创建 的 类 型 (就 像 
Widget) 完全 特 化 标准 模板 (MR swap) 。 这 就 是 我 们 现在 在 这 里 做 的 事情 。 





可 是 ， 就 像 我 说 的 ， 这 个 函数 还 不 能 编译 。 那 是 因为 它 试 图 访问 a 和 b 内 部 的 plmpl 指针 ， 
而 它们 是 private 的 。 我 们 可 以 将 我 们 的 特 化 声明 为 友 元 ， 但 是 惯例 是 不 同 的 : 让 Widget 声 
明 一 个 名 为 swap 的 public Ax A BHAA E Acie, FAIR PFE std::swap AiG ABT AX AH 


class Widget { // same as above, except for the 
public: // addition of the swap mem func 
void swap(Widget& other) 


using std::swap; // the need for this declaration 
// is explained later in this Item 


swap(pImpl, other.pImpl); // to swap Widgets, swap their 
// pImpl pointers 
J; 
namespace std { 
template<> // revised specialization of 
void swap<Widget>(Wwidget& a, // std::swap 
Widget& b) 
a.swap(b); // to swap Widgets, call their 


// swap member function 


这 个 不 仅 能 够 编译 ， 而 且 和 STL 容器 保持 一 致 ， 所 有 STL 容器 都 既 提 供 了 public swap 成 员 
PIR, RHETT std::swap 的 特 化 来 调用 这 些 成 员 函 数 。 


可 是 ， 假 设 Widget 和 Widgetlmpl 是 类 模板 ， 而 不 是 类 ， 或 许 因 此 我 们 可 以 参数 化 存储 在 
Widgetlmpl 中 的 数据 类 型 : 


template<typename T> 
class WidgetImpl { ... }; 


template<typename T> 
class Widget { ... }; 


在 Widget 中 加 入 一 个 swap X A RA (如 果 我 们 需要 ， 在 Widgetlmpl 中 也 加 一 个 ) 就 像 以 
前 一 样 容易 ， 但 我 们 特 化 std::swap 时 会 遇 到 麻烦 。 这 就 是 我 们 要 写 的 代码 : 


namespace std { 
template<typename T> 
void swap<Widget<T> >(Widget<T>& a, // error! illegal code! 
Widget<T>& b) 
{ a.swap(b); } 


这 看 上 去 非常 合理 ， 但 它 是 非法 的 。 我 们 试图 部 分 特 化 (partially specialize) 一 个 函数 模板 
(std::swap) ， 但 是 尽管 C++ 人 允许 类 模板 的 部 分 特 化 (partial specialization) ， 但 不 人 允许 汞 
数 模板 这 样 做 。 这 样 的 代码 不 能 编译 (尽管 一 些 编译 器 错误 地 接受 了 它 ) 。 


当 我 们 想 要 "部 分 特 化 "一 个 函数 模板 时 ， 通 常 做 法 是 简单 地 增加 一 个 重 载 。 看 起 来 就 像 这 样 : 


namespace std { 


template<typename T> // an overloading of std::swap 

void swap(Widget<T>& a, // (note the lack of "<...>" after 
Widget<T>& b) // "swap"), but see below for 

{ a.swap(b); } // why this isn't valid code 


通常 ， 重 载 函 数 模板 确实 很 不 错 ， 但 是 std 是 一 个 特殊 的 namespace， 规 则 对 它 也 有 特殊 的 
待遇 。 它 认可 完全 特 化 std 中 的 模板 ， 但 它 不 认可 在 std 中 增加 新 的 模板 (HARK, HR, 
以 及 其 它 任何 东西 ) 。std 的 内 容 由 C++ 标准 化 委员 会 单独 决定 ， 并 禁止 我 们 对 他 们 做 出 的 
决定 进行 增加 。 而 且 ， 禁 止 的 方式 使 你 无 计 可 施 。 打 破 这 条 禁 合 的 程序 差不多 的 确 可 以 编译 
和 运行 ， 但 它们 的 行为 是 未 定义 的 。 如 果 你 希望 你 的 软件 有 可 预期 的 行为 ， 你 就 不 应 该 向 std 
中 加 入 新 的 东西 。 


因此 该 怎么 做 呢 ?我 们 还 是 需要 一 个 方法 ， 既 使 其 他 人 能 调用 swap， 又 能 让 我 们 得 到 更 高 效 
的 模板 特 化 版 本 。 答 案 很 简单 。 我 们 还 是 声明 一 个 非 成 员 swap 来 调用 成 员 swap， 只 是 不 再 
将 那个 非 成 员 函 数 声明 为 std::swap 的 特 化 或 重 载 。 例 如 ， 如 果 我 们 的 Widget 相关 机 能 都 在 
namespace WidgetStuff 中 ， 它 看 起 来 就 像 这 个 祥子 : 


namespace WidgetStuff { 


// templatized WidgetImpl, etc. 
template<typename T> // as before, including the swap 
class Widget { ... }; // member function 
template<typename T> // non-member swap function; 
void swap(Widget<T>& a, // not part of the std namespace 


Widget<T>& b) 


a.swap(b); 


现在 ， 如 果 某 处 有 代码 使 用 两 个 Widget 对 象 调用 swap, C++ 的 名 字 查 找 规则 (以 参数 依赖 
查找 (argument-dependent lookup) 或 Koenig 查找 (Koenig lookup) 著称 的 特定 规则 ) 将 
找到 WidgetStuff 中 的 Widget 专用 版 本 。 而 这 正 是 我 们 想 要 的 。 


这 个 方法 无 论 对 于 类 模板 还 是 对 于 类 都 能 很 好 地 工作 ， 所 以 看 起 来 我 们 应 该 总 是 使 用 它 。 不 
幸 的 是 ， 此 处 还 是 存在 一 个 需要 为 类 特 化 std::swap 的 动机 (过 一 会 儿 我 会 讲 到 它 ) ， 所 以 如 
果 你 希望 你 的 swap 的 类 专用 版 本 在 尽 可 能 多 的 上 下 文中 都 能 够 调用 (而 你 也 确实 这 样 做 

了 ) ， 你 就 既 要 在 你 的 类 所 在 的 namespace 中 写 一 个 非 成 员 版 本 ， 又 要 提供 一 个 std::swap 
的 特 化 版 本 。 


顺便 提 一 下 ， 如 果 你 不 使 用 namespaces， 上 面 所 讲 的 一 切 依然 适用 (也 就 是 说 ， 你 还 是 需 
要 一 个 非 成 员 swap 来 调用 成 员 swap) ， 但 是 你 为 什么 要 把 你 的 类 ， 模 板 ， 男 数 ， 榴 举 (此 
处 作者 连用 了 两 个 词 (enum, enumerant) ， 不 知 有 何 区 别 译 者 注 ) 和 typedef 4 FRU 
在 全 局 namespace 中 呢 ? 你 觉得 合适 吗 ? 





迄今 为 止 我 所 写 的 每 一 件 事情 都 适用 于 swap 的 作成 者 ， 但 是 有 一 种 状况 值得 从 客户 的 观点 来 
看 一 看 。 假 设 你 写 了 一 个 画 数 模板 来 交换 两 个 对 象 的 值 : 


template<typename T> 
void doSomething(T& obji, T& obj2) 


swap(obji, obj2); 


} 


哪 一 个 swap 应 该 被 调用 呢 ? std 中 的 通用 版 本 ， 你 知道 它 必定 存在 ; std 中 的 通用 版 本 的 特 
化 ， 可 能 存在 ， 也 可 能 不 存在 ; T 专用 版 本 ， 可 能 存在 ， 也 可 能 不 存在 ， 可 能 在 一 个 
namespace 中 ， 也 可 能 不 在 一 个 namespace 中 (但 是 肯定 不 在 std 中 ) 。 究 竟 该 调用 哪 一 
个 呢 ? OR T 专用 版 本 存在 ， 你 希望 调用 它 ， 如 果 它 不 存在 ， 就 回 过 头 来 调用 std 中 的 通用 
版 本 。 如 下 这 样 就 可 以 符合 你 的 希望 : 


template<typename T> 
void doSomething(T& obji, T& obj2) 


using std::swap; // make std::swap available in this function 
swap(obji, obj2); // call the best swap for objects of type T 


} 


当 编 译 器 看 到 这 个 swap 调用 ， 他 会 寻找 正确 的 swap 版 本 来 调用 。C++ 的 名 字 查 找 规则 确 
保 能 找到 在 全 局 namespace 或 者 与 T 同一 个 namespace 中 的 下 专用 的 swap。 (例如 ， 如 
& T Æ namespace WidgetStuff 中 的 Widget， 编 译 器 会 利用 参数 依赖 查找 (argument- 
dependent lookup) 找到 WidgetStuff 中 的 swap。) 如 果 丁 专用 swap 不 存在 ， 编 译 器 将 使 
用 std 中 的 swap， 这 为 功 于 此 函数 中 的 using declaration 使 std::swap 在 此 可 见 。 尽 管 如 
此 ， 相 对 于 通用 模板 ， 编 译 器 还 是 更 喜欢 T 专用 的 std::swap 的 特 化 ， 所 以 如 果 std::swap 对 
T 进行 了 特 化 ， 则 特 化 的 版 本 会 被 使 用 。 


得 到 正确 的 swap 调用 是 如 此 地 容易 。 你 需要 小 心 的 一 件 事 是 不 要 对 调用 加 以 限定 ， 因 为 这 将 
影响 C++ 确定 该 调用 的 范 数 ， 如 果 你 这 样 写 对 swap 的 调用 ， 


std::swap(obj1, obj2); // the wrong way to call swap 


这 将 强制 编译 器 只 考虑 std 中 的 swap (包括 任何 模板 特 化 ) ， 因 此 排除 了 定义 在 别处 的 更 为 
适用 的 T 专用 版 本 被 调用 的 可 能 性 。 唉 ， 一 些 被 误导 的 程序 员 就 是 用 这 种 方法 限定 对 swap 
的 调用 ， 这 也 就 是 为 你 的 类 完全 地 特 化 std::swap 很 重要 的 原因 : 它 使 得 以 这 种 被 误导 的 方式 
写 出 的 代码 可 以 用 到 类 型 专用 的 swap 实现 。 (这 样 的 代码 还 存在 于 现在 的 一 些 标准 库 实现 
中 ， 所 以 它 将 有 利于 你 帮助 这 样 的 代码 尽 可 能 高 效 地 工作 。) 


到 此 为 止 ， 我 们 讨论 了 缺 省 的 swap， 成 员 swaps， 非 成 员 swaps, std::swap 的 特 化 版 本 ， 
以 及 对 swap 的 调用 ， 所 以 让 我 们 总 结 一 下 目前 的 状况 。 


首先 ， 如 果 swap 的 缺 省 实现 为 你 的 类 或 类 模板 提供 了 可 接受 的 性 能 ， 你 不 需要 做 任何 事 。 任 
何 试图 交换 你 的 类 型 的 对 象 的 人 都 会 得 到 缺 省 版 本 的 支持 ， 而 且 能 工作 得 很 好 。 


第 二 ， 如 果 swap 的 缺 省 实现 效率 不 足 (这 几乎 总 是 意味 着 你 的 类 或 模板 使 用 了 某 种 pimpl 
idiom 的 变种 ) ， 就 按照 以 下 步骤 来 做 : 


1. 提供 一 个 能 高 效 地 交换 你 的 类 型 的 两 个 对 象 的 值 的 public 的 swap AK A ENR, WM Rit 
会 儿 就 要 解释 的 动机 ， 这 个 豆 数 应 该 永远 不 会 抛 出 异常 。 


2. 在 你 的 类 或 模板 所 在 的 同一 个 namespace 中 提供 一 个 非 成 员 的 swap。 用 它 调 用 你 的 
swap Ak A EEX. 


3. 如 果 你 写 了 一 个 类 (不 是 类 模板 ) ， 就 为 你 的 类 特 化 std::swap。 用 它 也 调用 你 的 swap 成 


最 后 ， 如 果 你 调用 swap， 请 确保 在 你 的 函数 中 包含 一 个 using declaration 使 std::swap 可 
见 ， 然 后 在 调用 swap neve namespace 限定 条 件 。 


唯一 没有 解决 的 问题 就 是 我 的 警告 一 一 绝 不 要 让 swap 的 成 员 版 本 抛 出 异常 。 这 是 因为 swap 
的 非常 重要 的 应 用 之 一 是 为 类 (以 及 类 模板 ) 提供 强大 的 异常 安全 (exception-safety) 保 
证 。ltem 29 将 提供 所 有 的 细节 ， 但 是 这 项 技术 基于 swap 的 成 员 版 本 绝 不 会 抛 出 异常 的 假 
设 。 这 一 强制 约束 仅仅 应 用 在 成 员 版 本 上 ! 它 不 能 够 应 用 在 非 成 员 版 本 上 ， 因 为 swap 的 缺 省 
版 本 基于 拷贝 构造 和 拷贝 赋值 ， 而 在 通常 情况 下 ， 这 两 个 画 数 都 允许 抛 出 异常 。 如 果 你 宇 了 
一 个 swap 的 自 定义 版 本 ， 那 么 ， 典 型 情况 下 你 是 为 了 提供 一 个 更 有 效率 的 交换 值 的 方法 ， 你 
也 要 保证 这 个 方法 不 会 抛 出 异常 。 作 为 一 个 一 般 规则 ， 这 两 种 swap 的 特 型 业 紧 密 地 结合 在 一 
起 ， 因 为 高 效 的 交换 几乎 总 是 基于 内 建 类 型 (诸如 在 pimpl idiom 之 下 的 指针 ) 的 操作 ， 而 对 
内 建 类 型 的 操作 绝 不 会 抛 出 异常 。 


Things to Remember 


e 如 果 std::swap 对 于 你 的 类 型 来 说 是 低 效 的 ， 请 提供 一 个 swap KAA. FARIA 
swap 不 会 抛 出 异常 。 


。 如 果 你 提供 一 个 成 员 swap， 请 同时 提供 一 个 调用 成 员 swap 的 非 成 员 swap。 对 于 类 
( 非 模板 ) ， 还 要 特 化 std::swap。 


e 调用 swap 时 ， 请 为 std::swap 使 用 一 个 using declaration， 然 后 在 调用 swap 时 不 使 用 
任何 namespace 限定 条 件 。 


© 为 用 户 定义 类 型 完全 地 特 化 std 模板 没有 什么 问题 ， 但 是 绝 不 要 试图 往 std 中 加 入 任何 全 
新 的 东西 。 





Item 26: RE Aa REM HER X EEL 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 


发 布 : http://blog.csdn.net/fatalerror99/ 


只 要 你 定义 了 一 个 带 有 构造 事 数 和 析 构 函数 的 类 型 的 变量 ， 当 控制 流程 到 达 变 量 定义 的 时 候 
会 使 你 担负 构造 成 本 ， 而 当 变 量 离开 作用 域 的 时 候 会 使 你 担负 析 构 成 本 。 如 果 有 无 用 变量 造 
成 这 一 成 本 ， 你 就 要 尽 你 所 能 去 避免 它 。 


你 可 能 认为 你 从 来 不 会 定义 无 用 的 变量 ， 但 是 也 许 你 应 该 再 想 一 想 。 考 虑 下 面 这 个 画 数 ， 只 
要 password 的 长 度 满 足 要 求 ， 它 就 返回 一 个 password 的 加 密 版 本 。 如 果 eee AK, 
函数 就 会 抛 出 一 个 定义 在 标准 C++ 库 中 的 logic_error 类 型 的 异常 (参见 Item 54) 


// this function defines the variable "encrypted" too soon 
std::string encryptPassword(const std::string& password) 


{ 


using namespace std; 
string encrypted; 


if (password.length() < MinimumPasswordLength) { 
throw logic_error("Password is too short"); 
} 


// do whatever is necessary to place an 


// encrypted version of password in encrypted 
return encrypted; 


对 象 encrypted 在 这 个 函数 中 并 不 是 完全 无 用 ， 但 是 如 果 抛 出 了 一 个 异常 ， 它 就 是 无 用 的 。 
换 名 话说， 即使 encryptPassword 抛 出 一 个 异常 ， 你 也 要 为 构造 和 析 构 encrypted 付出 代 
价 。 因 此 得 出 以 下 结论 : 你 最 好 将 encrypted 的 定义 推迟 到 你 确信 你 真 的 需要 它 的 时 候 : 


// this function postpones encrypted's definition until it's truly necessary 
std::string encryptPassword(const std::string& password) 
{ 


using namespace std; 


if (password.length() < MinimumPasswordLength) { 
throw logic_error("Password is too short"); 
} 


string encrypted; 


// do whatever is necessary to place an 


// encrypted version of password in encrypted 
return encrypted; 


这 一 代码 仍然 没有 达到 它 本 可 以 达到 的 那样 紧凑 ， 因 为 定义 encrypted 的 时 候 没 有 任何 初始 
化 参数 。 这 就 意味 着 很 多 情况 下 将 使 用 它 的 缺 省 构造 画 数 ， 对 于 一 个 对 象 你 首先 应 该 做 的 就 
是 给 它 一 些 值 ， 这 经 常 可 以 通过 赋值 来 完成 。ltem 4 解释 了 为 什么 缺 省 构造 (default- 
constructing) 一 个 对 象 然后 赋值 给 它 比 用 你 真正 需要 它 持 有 的 值 初始 化 它 更 低 效 。 那 个 分 析 
也 适用 于 此 。 例 如 ， 假 设 encryptPassword 的 核心 部 分 是 在 这 个 画 数 中 完成 的 : 


void encrypt(std::string& s); // encrypts s in place 


#82, encryptPassword 就 可 以 这 样 实现 ， 即 使 它 还 不 是 最 好 的 方法 : 


// this function postpones encrypted's definition until 
// it's necessary, but it's still needlessly inefficient 
std::string encryptPassword(const std::string& password) 


{ 
ta // check length as above 


string encrypted; // default-construct encrypted 
encrypted = password; // assign to encrypted 


encrypt(encrypted); 
return encrypted; 


一 个 更 可 取得 方法 是 用 password 初始 化 encrypted, MMD SBLH WAR ARS 


构造 : 


// finally, the best way to define and initialize encrypted 
std::string encryptPassword(const std::string& password) 


{ 
ewe // check length 


string encrypted(password); // define and initialize 
// via copy constructor 


encrypt(encrypted); 
return encrypted; 


} 


这 个 建议 就 是 本 Item 的 标题 中 的 “只 要 有 可 能 (as long as possible) ”的 真正 含义 。 你 不 仅 应 
该 推迟 一 个 变量 的 定义 直到 你 不 得 不 用 它 之 前 的 最 后 一 刻 ， 而 且 应 该 试图 推迟 它 的 定义 直到 
你 得 到 了 它 的 初始 化 参数 。 通 过 这 样 的 做 法 ， 你 可 以 避免 构造 和 析 构 无 用 对 象 ， 而 且 还 可 以 
避免 不 必要 的 缺 省 构造 。 更 进一步 ， 通 过 在 它们 的 含义 已 经 非常 明确 的 上 下 文中 初始 化 它 
们 ， 有 助 于 对 变量 的 作用 文档 化 。 

“但 是 对 于 循环 会 如 何 ? "你 可 能 会 有 这 样 的 疑问 。 如 果 一 个 变量 仅仅 在 一 个 循环 内 使 用 ， 是 循 
环 外 面 定义 它 并 在 每 次 循环 迭代 时 赋值 给 它 更 好 一 些 ， 还 是 在 循环 内 部 定义 这 个 变量 更 好 一 
些 呢 ?也 就 是 说 ， 下 面 这 两 个 大 致 的 结构 中 哪个 更 好 一 些 ? 


// Approach A: define outside loop // Approach B: define inside loop 


Widget w; 
for (int i= 0; i < n; ++i){ for (int i = 0; i<n; ++i) { 

w = some value dependent on i; Widget w(some value dependent on i); 
} 


这 里 我 将 一 个 类 型 string 的 对 象 换 成 了 一 个 类 型 Widget 的 对 象 ， 以 避免 对 这 个 对 象 的 构造 、 
he ena 


对 于 Widget 的 操作 而 言 ， 就 是 下 面 这 两 个 方法 的 成 本 : 
。 方法 A : 1 个 构造 函数 + 1 个 析 构 函数 + n 个 赋值 。 
。 方法 B : n THERA +n 个 析 构 范 数 。 


对 于 那些 赋值 的 成 本 低 于 一 个 构造 画 数 / 析 构 函 u 方法 A 通常 更 高 效 。 特 别 是 
在 n 变 得 很 大 的 情况 下 。 否 则 ， 方 法 B 可 能 更 好 一 些 。 此 外 ， 方 法 A 与 方法 B 相 比 ， 使 得 
名 宇内 在 一 个 较 大 的 区 域 (包含 循环 的 那个 区 域 ) AHTN, à 这 可 能 会 破坏 程序 的 易 理解 性 
和 可 维护 性 。 因 此 得 出 以 下 结论 : 除非 你 确信 以 下 两 点 : (1) 赋值 比 构造 范 数 / 析 构 范 数 对 成 
ABE, MA (2) 你 正在 涉及 你 的 代码 中 的 性 能 敏感 的 部 分 ， 否 则 ， 你 应 该 默认 使 用 方法 
B。 


Things to Remember 


。 只 要 有 可 能 就 推迟 变量 定义 。 这 样 可 以 增加 程序 的 清晰 度 并 提高 程序 的 性 能 。 


Item 27: 将 强制 转型 减 到 最 少 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


C++ 的 规则 设计 为 保证 不 会 发 生 类 型 错误 。 在 理论 上 ， 如 果 你 的 程序 想 顺 利 地 通过 编译 ， 你 
就 不 应 该 试图 对 任何 对 象 做 任何 不 安全 的 或 无 意义 的 操作 。 这 是 一 个 非常 有 价值 的 保证 ， 你 
不 应 该 轻易 地 放弃 它 。 


不 幸 的 是 ， 强 制 转型 破坏 了 类 型 系统 。 它 会 引起 各 种 各 样 的 麻烦 ， 其 中 一 些 容 易 被 察觉 ， 另 
一 些 则 格外 地 微妙 。 如 果 你 从 C，Java， 或 CH 转 到 C++， 请 一 定 注意 ， 因 为 强制 转型 在 那 
些 语言 中 比 在 C++ 中 更 有 必要 ， 危 险 也 更 少 。 但 是 C++ FEC, hte Java, hh CH 
在 这 一 语言 中 ， 强 制 转 型 是 一 个 你 必须 全 神 贯 注 才 可 以 靠近 的 特性 。 


我 们 就 从 回顾 强制 转型 的 语法 开始 ， 因 为 对 于 同样 的 强制 转型 通常 有 三 种 不 同 的 写法 。C 风格 
(C-style) 强制 转型 如 下 : 


(T) expression // cast expression to be of type T 


KAULA (Function-style) 强制 转型 使 用 这 样 的 语法 : 


T(expression) // cast expression to be of type T 


这 两 种 形式 之 间 没 有 本 质 上 的 不 同 ， 它 纯粹 就 是 一 个 把 括号 放 在 哪 的 问题 。 我 把 这 两 种 形式 
称 为 旧 风 格 (old-style) 的 强制 转型 。 


C++ 同时 提供 了 四 种 新 的 强制 转型 形式 〈 通 常 称 为 新 风格 的 或 C++ 风格 的 强制 转型 ) 


const_cast<T>(expression) 
dynamic_cast<T>(expression) 
reinterpret_cast<T>(expression) 
static_cast<T>(expression) 


每 一 种 适用 于 特定 的 目的 : 


e const_cast 一 般 用 于 强制 消除 对 象 的 常量 性 。 它 是 唯一 能 做 到 这 一 点 的 C++ 风格 的 强制 
转型 。 

e dynamic_cast 主要 用 于 执行 “安全 的 向 下 转型 (safe downcasting) ”， 人 也 就 是 说 ， 要 确定 
一 个 对 象 是 否 是 一 个 继承 体系 中 的 一 个 特定 类 型 。 它 是 唯一 不 能 用 旧 风 格 语法 执行 的 强 
制 转型 。 也 是 唯一 可 能 有 重大 运行 时 代价 的 强制 转型 。 〈 过 一 会 儿 我 再 提供 细节 。) 


e reinterpret_cast 是 特意 用 于 底层 的 强制 转型 ， 导 致 实现 依赖 (implementation- 
dependent) 就 是 说 ， 不 可 移植 ) 的 结果 ， 例 如 ， 将 一 个 指针 转型 为 一 个 整数 。 这 样 的 
强制 转型 在 底层 代码 以 外 应 该 极为 军 见 。 在 本 书 中 我 只 用 了 一 次 ， 而 且 还 仅仅 是 在 讨论 
你 应 该 如 何 为 裸 内 存 (raw memory) 写 一 个 调谐 分 配 者 (debugging allocator) 的 时 候 

(参见 Item 50) 。 


e static_cast 可 以 被 用 于 强制 隐 型 转换 (例如 ，non-const 对 象 转 型 为 const 对 象 〈 就 像 
Item 3 中 的 ) , int 转型 为 double， 等 等 ) 。 它 还 可 以 用 于 很 多 这 样 的 转换 的 反 向 转换 
(例如 ，void* 指针 转型 为 有 类 型 指针 ， 基 类 指针 转型 为 派生 类 指针 ) ， 但 是 它 不 能 将 一 
个 const 对 象 转型 为 non-const 对 象 。 (只 有 const_cast 能 做 到 。) 


旧 风 格 的 强制 转型 依然 合法 ， 但 是 新 的 形式 更 可 取 。 首 先 ， 在 代码 中 它们 更 容易 识别 (无 论 
是 人 还 是 像 grep 这 祥 的 工具 都 是 如 此 ) ， 这 样 就 简化 了 在 代码 中 寻找 类 型 系统 被 破坏 的 地 方 
的 过 程 。 第 二 ， 更 精确 地 指定 每 一 个 强制 转型 的 目的 ， 使 得 编译 器 诊断 使 用 错误 成 为 可 能 。 
例如 ， 如 果 你 试图 使 用 一 个 const_cast 以 外 的 新 风格 强制 转型 来 消除 常量 性 ， 你 的 代码 将 无 
法 编译 。 

当 我 要 调用 一 个 explicit 构造 画 数 用 来 传递 一 个 对 象 给 一 个 男 数 的 时 候 ， 大 概 就 是 我 仅 有 的 使 
用 旧 风 格 的 强制 转换 的 时 候 。 例 如 : 


class Widget { 
public: 
explicit Widget(int size); 
J; 
void doSomework(const Widget& w); 


doSomeWork(Widget(15)); // create Widget from int 
// with function-style cast 


doSomework(static_cast<widget>(15)); // create Widget from int 
// with C++-style cast 


由 于 某 种 原因 ， 有 条 不 北 的 对 象 创 建 感觉 上 不 像 一 个 强制 转型 ， 所 以 在 这 个 强制 转型 中 我 多 半 
会 用 画 数 风格 的 强制 转型 代 蔡 static_cast。 反 过 来 说 ， 在 你 写 出 那些 导致 core dump 的 代码 

时 ， 你 通常 都 感觉 你 有 合理 的 理由 ， 所 以 你 最 好 忽略 你 的 感觉 并 始终 都 使 用 新 风格 的 强制 转 

型 。 

很 多 程序 员 认 为 强制 转型 除了 告诉 编译 器 将 一 种 类 型 看 作 另 一 种 之 外 什么 都 没 做 ， 但 这 是 错 

误 的 。 任 何 种 类 的 类 型 转换 (无 论 是 通过 强制 转型 的 显 式 的 还 是 编译 器 添加 的 隐 式 的 ) 都 会 

导致 运行 时 的 可 执行 代码 。 例 如 ， 在 这 个 代码 片断 中 ， 


int x, y; 


double d = static_cast<double>(x)/y; // divide x by y, but use 
// floating point division 


int x 到 double 的 强制 转型 理所当然 要 生成 代码 ， 因 为 在 大 多 数 系统 架构 中 ， 一 个 int 的 底层 
表示 与 double 的 不 同 。 这 可 能 还 不 怎么 倒 人 吃惊 ， 但 是 下 面 这 个 例子 可 能 会 让 你 稍微 开 一 下 
HR : 


class Base { ... }; 

class Derived: public Base { ... }; 

Derived d; 

Base *pb = &d; // implicitly convert Derived* 一 Base* 


这 里 我 们 只 是 创建 了 一 个 指向 派生 类 对 象 的 基 类 指针 ， 但 是 有 时 候 ， 这 两 个 指针 的 值 并 不 相 
同 。 在 当前 情况 下 ， 会 在 运行 时 在 Derived* 指针 上 应 用 一 个 偏 移 量 以 得 到 正确 的 Base* 指针 
值 。 


这 后 一 个 例子 表明 一 个 单一 的 对 象 ( 例 如， 一 个 类 型 为 Derived 的 对 象 ) 可 能 会 有 不 止 一 个 
地 址 (例如 ， 它 的 被 一 个 Base* 指针 指向 的 地 址 和 它 的 被 一 个 Derived* 指针 指向 的 地 址 ) 。 
这 在 C 中 就 不 会 发 生 ， 也 不 会 在 Java 中 发 生 ， 也 不 会 在 C# 中 发 生 ， 它 仅 在 C++ 中 发 生 。 
实际 上 ， 如 果 使 用 了 多 继承 ， 则 一 定 会 发 生 ， 但 是 在 单 继承 下 也 会 发 生 。 与 其 它 事 情 合 在 一 
起 ， 就 意味 着 你 应 该 总 是 避免 对 C++ 如 何 摆 放 事物 做 出 假设 ， 你 当然 也 不 应 该 基于 这 样 的 假 
设 执 行 强制 转型 。 例 如 ， 将 一 个 对 象 的 地 址 强制 转型 为 char* 指针 ， 然 后 对 其 使 用 指针 运算 ， 
这 几乎 总 是 会 导致 未 定义 行为 。 


但 是 请 注意 我 说 一 个 偏 移 量 是 “有 时 ”被 需要 。 对 象 摆 放 的 方法 和 他 们 的 地 址 的 计算 方法 在 不 同 
的 编译 器 之 间 有 所 变化 。 这 就 意味 着 仅仅 因为 你 的 “我 知道 事物 是 如 何 摆 放 的 ”而 使 得 强制 转型 
能 工作 在 一 个 平台 上 ， 并 不 意味 着 它们 也 能 在 其 它 平台 工作 。 这 个 世界 被 通过 痛苦 的 道路 学 
得 这 条 经 验 的 可 惟 的 程序 员 所 充满 。 


关于 强制 转型 的 一 件 有 趣 的 事 是 很 容易 写 出 看 起 来 对 (在 其 它 语言 中 也 许 是 对 的 ) 实际 上 错 
的 东西 。 例 如 ， 许 多 应 用 框架 (application framework) BREE RAR OM ABMS 
首先 调用 它们 的 基 类 对 应 物 。 假 设 我 们 有 一 个 Window 基 类 和 一 个 SpecialWindow 派生 类 ， 
它们 都 定义 了 虚 函 数 onResize。 进 一 步 假设 SpecialWindow 的 onResize 被 期 望 首先 调用 
Window 的 onResize。 这 就 是 实现 这 个 的 一 种 方法 ， 它 看 起 来 正确 实际 并 不 正确 : 


class Window { // base class 
public: 
virtual void onResize() { ... } // base onResize impl 
}; 
class SpecialWindow: public Window { // derived class 
public: 
virtual void onResize() { // derived onResize impl; 
static_cast<Window>(*this).onResize(); // cast *this to Window, 
// then call its onResize; 
// this doesn't work! 
ee // do Specialwindow- 
} // specific stuff 
}; 


我 突出 了 代码 中 的 强制 转型 。 (这 是 一 个 新 风格 的 强制 转型 ， 但 是 使 用 旧 风 格 的 强制 转型 也 于 
事 无 补 。) 正 像 你 所 期 望 的 ， 代 码 将 this 强制 转型 为 一 个 Window。 因 此 调用 onResize 的 结 
果 就 是 调用 Window::onResize。 你 也 许 并 不 期 待 它 没有 调用 当前 对 象 的 那个 范 数 ! 作为 蔡 
代 ， 强 制 转 型 创建 了 一 个 this 的 基 类 部 分 的 新 的 ， 临 时 的 拷贝 ， 然 后 调用 这 个 拷贝 的 
onResize ! 上 面 的 代码 没有 调用 当前 对 象 的 Window::onResize， 然 后 再 对 这 个 对 象 执行 
SpecialWindow 特有 的 动作 一 一 它 在 对 当前 对 象 执行 SpecialWindow 特有 的 动作 之 前 ， 调 用 
了 当前 对 象 的 基 类 部 分 的 一 份 拷贝 的 Window::onResize。 如 果 Window::onResize 改变 了 当 
前 对 象 〈 可 能 性 并 不 小 ， 因 为 onResize 是 一 个 non-const X AWM) ， 当 前 对 象 并 不 会 改 
变 。 作 为 蔡 代 ， 那 个 对 象 的 一 份 拷贝 被 改变 。 如 果 SpecialWindow::onResize 改变 了 当前 对 
象 ， 无 论 如 何 ， 当 前 对 象 将 被 改变 ， 导 致 的 境况 是 那些 代码 使 当前 对 象 进入 一 种 病态 ， 没 有 
做 基 类 的 变更 ， 却 做 了 派生 类 的 变更 。 


解决 方法 就 是 消除 强制 转型 ， 用 你 真正 想 表 达 的 来 代替 它 。 你 不 应 该 哄骗 编译 器 将 *this 当 作 
一 个 基 类 对 象 来 处 理 ， 你 应 该 调用 当前 对 象 的 onResize 的 基 类 版 本 。 就 是 这 样 : 


class SpecialWindow: public Window { 


public: 
virtual void onResize() { 
Window: :onResize(); // call Window: :onResize 
oe // on *this 
} 
}; 


这 个 例子 也 表明 如 果 你 发 现 自 己 要 做 强制 转型 ， 这 就 是 你 可 能 做 错 了 某 事 的 一 个 信号 。 在 你 
想 用 dynamic_cast 时 尤其 如 此 。 


在 探究 dynamic_cast 的 设计 意图 之 前 ， 值 得 留意 的 是 很 多 dynamic_cast 的 实现 都 相当 慢 。 
例如 ， 至 少 有 一 种 通用 的 实现 部 分 地 基于 对 类 名 字 进 行 字 符 串 比较 。 如 果 你 在 一 个 位 于 四 层 
深 的 单 继承 体系 中 的 对 象 上 执行 dynamic_cast， 在 这 样 一 个 实现 下 的 每 一 个 dynamic_cast 
都 要 付出 相当 于 四 次 调用 strcmp 来 比较 类 名 字 的 成 本 。 对 于 一 个 更 深 的 或 使 用 了 多 继承 的 继 


承 体系 ， 付 出 的 代价 会 更 加 昂贵 。 一 些 实现 用 这 种 方法 工作 是 有 原因 的 (它们 不 得 不 这 样 做 
以 支持 动态 链接 ) 。 尽 管 如 此 ， 除 了 在 普通 意义 上 警惕 强制 转型 外 ， 在 性 能 敏感 的 代码 中 ， 
你 应 该 特别 警惕 dynamic_casts。 


对 dynamic_cast 的 需要 通常 发 生 在 这 种 情况 下 : 你 要 在 一 个 你 确信 为 派生 类 的 对 象 上 执行 派 
生 类 的 操作 ， 但 是 你 只 能 通过 一 个 基 类 的 指针 或 引用 来 操控 这 个 对 象 。 有 两 个 一 般 的 方法 可 
以 避免 这 个 问题 。 


第 一 个 ， 使 用 存储 着 直接 指向 派生 类 对 象 的 指针 (通常 是 智能 指针 
器 ， 从 而 消除 通过 基 类 接口 操控 这 个 对 象 的 需要 。 例 如 ， 如 果 在 我 们 的 
Window/SpecialWindow 继承 体系 中 ， 只 有 SpecialWindows 支持 blinking， 对 于 这 样 的 做 
法 : 


参见 Item 13) WA 





class Window { ... }; 


class SpecialWindow: public Window { 
public: 
void blink(); 


J; 
typedef // see Item 13 for info 
std::vector<std::tri::shared_ptr<Window> > VPW; // on tri::shared_ptr 


VPW winPtrs; 


for (VPW::iterator iter = winPtrs.begin(); // undesirable code: 
iter != winPtrs.end(); // uses dynamic_cast 
++iter) { 


if (SpecialWindow *psw = dynamic_cast<SpecialWindow*>(iter->get())) 
psw->blink(); 


设法 用 如 下 方法 代替 : 


typedef std::vector<std::tri::shared_ptr<SpecialWindow> > VPSW; 


VPSW winPtrs; 


for (VPSW::iterator iter = winPtrs.begin(); // better code: uses 
iter != winPtrs.end(); // no dynamic_cast 
++iter) 


(*iter)->blink(); 


当然 ， 这 个 方法 不 允许 你 在 同一 个 容器 中 存储 所 有 可 能 的 Window 的 派生 类 的 指针 。 为 了 与 
不 同 的 窗口 类 型 一 起 工作 ， 你 可 能 需要 多 个 类 型 安全 (type-safe) 的 容器 。 


一 个 候选 方法 可 以 让 你 通过 一 个 基 类 的 接口 操控 所 有 可 能 的 Window 派生 类 ， 就 是 在 基 类 中 


提供 一 个 让 你 做 你 想 做 的 事情 的 虚 函 数 。 例 如 ， 尽 管 只 有 SpecialWindows 能 blink, T # 
中 声明 这 个 画 数 ， 并 提供 一 个 什么 都 不 做 的 缺 省 实现 或 许 是 有 意义 的 : 


class Window { 


public: 
virtual void blink() {} // default impl is no-op; 
ae // see Item 34 for why 

tap // a default impl may be 


// a bad idea 


class SpecialWindow: public Window { 

public: 
virtual void blink() { ... } // in this class, blink 
ind // does something 

}; 


typedef std::vector<std::tri::shared ptr<window> > VPW; 

VPW winPtrs; // container holds 
// (ptrs to) all possible 
// Window types 


for (VPW::iterator iter = winPtrs.begin(); 





iter != winPtrs.end(); 
++iter) // note lack of 
(*iter)->blink(); // dynamic_cast 
无 论 哪 种 方法 一 一 使 用 类 型 安全 的 容器 或 在 继承 体系 中 上 移 虚 函数 一 一 都 不 是 到 处 适用 的 ， 


但 在 很 多 情况 下 ， 它 们 提供 了 dynamic_casting 之 外 另 一 个 可 行 的 候选 方法 。 当 它们 可 用 
时 ， 你 应 该 加 以 利用 。 


你 应 该 绝对 避免 的 一 件 未 西 就 是 包含 了 极 联 dynamic_casts 的 设计 ， 也 就 是 说 ， 看 起 来 类 似 
这 样 的 任何 东西 : 


class Window { ... }; 
// derived classes are defined here 
typedef std::vector<std::tri::shared_ptr<Window> > VPW; 


VPW winPtrs; 


for (VPW::iterator iter = winPtrs.begin(); iter != winPtrs.end(); ++iter) 


if (Specialwindow1 *pswi = 
dynamic_cast<SpecialWindow1*>(iter->get())) { ... } 


else if (SpecialWindow2 *psw2 = 
dynamic_cast<SpecialWindow2*>(iter->get())) { ... } 


else if (SpecialWindow3 *psw3 = 
dynamic_cast<SpecialWindow3*>(iter->get())) { ... } 


这 样 的 C++ 会 生成 的 代码 又 大 又 慢 ， 而 且 很 脆弱 ， 因 为 每 次 Window 类 继承 体系 发 生变 化 ， 
所 有 这 样 的 代码 都 要 必须 被 检查 ， 以 确认 是 否 需要 更 新 。 〈 例 如 ， 如 果 增 加 了 一 个 新 的 派生 
类 ， 在 上 面 的 极 联 中 或 许 就 需要 加 入 一 个 新 的 条 件 分 支 。) 看 起 来 类 似 这 样 的 代码 应 该 总 是 
HETEKIA AIEI k Rk 


好 的 C++ 极 少 使 用 强制 转型 ， 但 在 通常 情况 下 完全 去 除 也 不 实际 。 例 如 ， 第 118 HM int 到 
double 的 强制 转型 ， 就 是 对 强制 转型 的 合理 运用 ， 虽 然 它 并 不 是 绝对 必要 。 (那些 代码 应 该 
被 重 写 ， 声 明 一 个 新 的 类 型 为 double 的 变量 ， 并 用 x 的 值 进行 初始 化 。) 就 像 大 多 数 可 疑 的 
结构 成 分 ， 强 制 转 型 应 该 被 尽 可 能 地 隔离 ， 典 型 情况 是 隐藏 在 本 数 内 部 ， 用 本 数 的 接口 保护 
调用 者 远离 内 部 的 污秽 的 工作 。 


Things to Remember 


。 避免 强制 转型 的 随时 应 用 ， 特 别 是 在 性 能 敏感 的 代码 中 应 用 dynamic_casts， 如 果 一 个 设 
计 需 要 强制 转型 ， 设 法 开发 一 个 没有 强制 转型 的 候选 方案 。 

。 如 果 必 须要 强制 转型 ， 设 法 将 它 隐 藏 在 一 个 落 数 中 。 客 户 可 以 用 调用 那个 芳 数 来 代替 在 
他 们 自己 的 代码 中 加 入 强制 转型 。 


。 尽量 用 C++ 风格 的 强制 转型 替换 旧 风 格 的 强制 转型 。 它 们 更 容易 被 注意 到 ， 而 且 他 们 做 
的 事情 也 更 加 明确 。 


Item 28: 避免 返回 对 象 内 部 构件 的 “句柄 ” 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


假设 你 正在 一 个 包含 矩形 的 应 用 程序 上 工作 。 每 一 个 和 矩形 都 可 以 用 它 的 左上 角 和 右 下 角 表 示 

出 来 。 为 了 将 一 个 Rectangle 对 象 保 持 在 较 小 状态 ， 你 可 能 决定 那些 点 的 定义 的 域 不 应 该 包 

含 在 Rectangle 本 身 之 中 ， 更 合适 的 做 法 是 放 在 一 个 由 Rectangle 指向 的 辅助 的 结构 体 中 : 
class Point { // class for representing points 


public: 
Point(int x, int y); 


void setX(int newVal); 
void setY(int newVal); 


}; 
struct RectData { // Point data for a Rectangle 
Point ulhc; // ulhc = " upper left-hand corner" 
Point Irhc; // lrhc = " lower right-hand corner" 
3; 


class Rectangle { 


private: 
std::tri::shared_ptr<RectData> pData; // see Item 13 for info on 
}; // tri::shared_ptr 


由 于 Rectangle 的 客户 需要 有 能 力 操控 Rectangle 的 区 域 ， 因 此 类 提供 了 upperLeft 和 
lowerRight H. JÆ, Poit 是 一 个 用 户 定义 类 型 ， 所 以 ， 留 心 ltem 20 关于 在 典型 情况 
下 ， 以 传 引用 的 方式 传递 用 户 定 义 类 型 比 传 值 的 方式 更 加 高 效 的 观点 ， 这 些 画 数 返 回 引 向 底 
层 Point 对 象 的 引用 : 


class Rectangle { 
public: 


Point& upperLeft() const { return pData->ulhc; } 
Point& lowerRight() const { return pData->l1rhc; } 


T 


这 个 设计 可 以 编译 ， 但 它 是 错误 的 。 实 际 上 ， 它 是 自 相 矛盾 的 。 一 方面 ，upperLeft 和 
lowerRight 是 被 声明 为 const 的 成 员 画 数 ， 因 为 它们 被 设计 成 仅仅 给 客户 提供 一 个 获得 
Rectangle 的 点 的 方法 ， 而 不 允许 客户 改变 这 个 Rectangle (参见 Item 3) 。 另 一 方面 ， 两 个 
函数 都 返回 引 向 私有 的 内 部 数据 的 引用 一 一 调用 者 可 以 利用 这 些 引用 修改 内 部 数据 ! 例如 : 





Point coordi(0, 0); 
Point coord2(100, 100); 


const Rectangle rec(coord1, coord2); // rec is a const rectangle from 
// (©, ©) to (100, 100) 


rec.upperLeft().setX(50); // now rec goes from 
// (50, ©) to (100, 100)! 


请 注意 这 里 ，upperLeft 的 调用 者 是 怎样 利用 返回 的 rec 的 内 部 Point 数据 成 员 的 引用 来 改变 
这 个 成 员 的 。 但 是 rec 却 被 期 望 为 const ! 


x 


这 直接 引出 两 条 经 验 。 第 一 ， 一 个 数据 成 员 被 封装 ， 但 是 具有 最 高 可 访问 级 别 的 函数 还 是 能 
够 返回 引 向 它 的 引用 。 在 当前 情况 下 ， 虽然 ulhc 和 Irhc 被 声明 为 private， 它 们 还 是 被 有 效 地 
公开 了 ， 因 为 public BAX upperLeft 和 lowerRight 返回 了 引 向 它们 的 引用 。 第 二 ， 如 果 一 个 
const 成 员 画 数 返回 一 个 引用 ， 引 向 一 个 与 某 个 对 象 有 关 并 存储 在 这 个 对 象 本 身 之 外 的 数据 ， 

这 个 图 数 的 调用 者 就 可 以 改变 那个 数据 (这 正 是 二 进 制 位 常量 性 的 局 限 性 (参见 Item 3) 的 
一 个 副作用 ) 。 


我 们 前 面 做 的 每 件 事 都 涉及 到 成 员 函 数 返 回 的 引用 ， 但 是 ， 如 果 它 们 返回 指针 或 者 迭代 器 ， 
因为 同样 的 原因 也 会 存在 同样 的 问题 。 引 用 ， 指 针 ， 和 迭代 器 都 是 句柄 (hande) (HAH 
它 对 象 的 方法 ) ， 而 返回 一 个 对 象 内 部 构件 的 句柄 总 是 面临 危及 对 象 封 装 安全 的 风险 。 就 像 
我 们 看 到 的 ， 它 同时 还 能 导致 const 成 员 画 数 改变 了 一 个 对 象 的 状态 。 


我 们 通常 认为 一 个 对 象 的 “内 部 构件 "就 是 它 的 数据 成 员 ， 但 是 不 能 被 常规 地 公开 访问 的 成 员 画 
数 (也 就 是 说 ， 它 是 protected 或 private 的 ) 也 是 对 象 内 部 构件 的 一 部 分 。 同 样 地 ， 不 要 返 
回 它 们 的 句柄 也 很 重要 。 这 就 意味 着 你 绝 不 应 该 有 一 个 成 员 画 数 返 回 一 个 指向 拥有 较 小 的 可 
访问 级 别 的 成 员 画 数 的 指针 。 如 果 你 这 样 做 了 ， 它 的 可 访问 级 别 就 会 与 那个 拥有 较 大 的 可 访 
问 级 别 的 函数 相同 ， pie ie 文 个 拥有 较 小 的 可 访问 级 别 的 画 数 的 指针 ， 然 后 
就 可 以 通过 这 个 指针 调用 这 个 男 数 。 


无 论 如 何 ， 返 回 指向 成 员 画 数 的 指针 的 函数 是 难得 一 见 的 ， 所 以 让 我 们 把 注意 力 返 回 到 
Rectangle 类 和 它 的 upperLeft 和 lowerRight Ak REAR. FE HP PH EY Fh] MERA 
需 简 单 地 将 const 用 于 它们 的 返回 类 型 就 可 以 排除 : 


class Rectangle { 
public: 


const Point& upperLeft() const { return pData->ulhc; } 
const Point& lowerRight() const { return pData->l1rhc; } 


通过 这 个 修改 的 设计 ， 客 户 可 以 读 取 定 义 一 个 矩形 的 Points， 但 他 们 不 能 写 它 们 。 这 就 意味 
着 将 upperLeft 和 upperRight 声明 为 const 不 再 是 一 名 空话， 因为 他 们 不 再 允许 调用 者 改变 
对 象 的 状态 。 至 于 封装 的 问题 ， 我 们 总 是 故意 让 客户 看 到 做 成 一 个 Rectangle 的 Points, FAT 


以 这 是 封装 的 一 个 故意 的 放松 之 处 。 更 重要 的 ， 它 是 一 个 有 限 的 放松 : 只 有 读 访问 是 被 这 些 
画 数 允 许 的 ， 写 访问 依然 被 禁止 。 


虽然 如 此 ，upperLeft 和 lowerRight 仍然 返回 一 个 对 象 内 部 构件 的 句柄 ， 而 这 有 可 能 造成 其 
方面 的 问题 。 特 别 是 ， 这 会 导致 空 是 句柄 : 引用 了 不 再 存在 的 对 象 的 构件 的 句柄 。 Saud 
的 对 象 的 最 普通 的 来 源 就 是 函数 返回 值 。 例 如 ， 考 虑 一 个 画 数 ， 返 回 在 一 个 矩形 窗 体 中 的 
GUI 对 象 的 bounding box : 


class GUIObject { ... }; 
const Rectangle // returns a rectangle by 
boundingBox(const GUIObject& obj); // value; see Item 3 for why 


// return type is const 


RE, BEB POURS EAT : 


GUIObject *pgo; // make pgo point to 

oc // some GUIObject 

const Point *pUpperLeft = // get a ptr to the upper 
&(boundingBox(*pgo) .upperLeft()); // left point of its 


// bounding box 


对 boundingBox 的 调用 会 返回 一 个 新 建 的 临时 的 Rectangle 对 象 。 这 个 对 象 没有 名 字 ， 所 以 
我 们 就 称 它 为 temp。 于 是 upperLeft 就 在 temp 上 被 调用 ， 这 个 调用 返回 一 个 引 向 temp 的 一 
个 内 部 构件 的 引用 ， 特 别 是 ， 它 是 由 Points 构成 的 。 随 后 pUpperLeft 指向 这 个 Point 对 象 。 
到 此 为 止 ， 一 切 正 常 ， 但 是 我 们 无 法 继续 了 ， 因 为 在 这 个 语句 的 末尾 ，boundingBox 的 返回 
值 一 一 temp 一 被 销毁 了 ， 这 将 间接 导致 temp 的 Points 的 析 构 。 接 下 来 ， 剩 下 
pUpperLeft 指向 一 个 已 经 不 再 存在 的 对 象 ; pUpperLeft 空 基 在 创建 它 的 语句 的 末尾 ! 


这 就 是 为 什么 任何 返回 一 个 对 象 的 内 部 构件 的 句柄 的 函数 都 是 危险 的 。 它 与 那个 句柄 是 指 

针 ， 引 用 ， 还 是 迭代 器 没什么 关系 。 它 与 是 否 受到 cosnt 的 限制 没什么 关系 。 它 与 那个 成 员 

0 Gz const 没什么 关系 。 全 部 的 问题 在 于 一 个 句柄 被 返回 了 ， 因 为 一 
这 样 做 了 ， 你 就 面临 着 这 个 句柄 比 它 引 用 的 对 象 更 长 寿 的 风险 。 


这 并 不 意味 着 你 永远 不 应 该 让 一 个 成 员 画 数 返 回 一 个 句柄 。 有 时 你 必须 如 此 。 例 如 ， 
operator[] 允许 你 从 string 和 vector 中 取出 单独 的 元 素 ， 而 这 些 operator[]s 就 是 通过 返回 引 
向 容器 中 的 数据 的 引用 来 工作 的 (参见 tme 3) 一 一 当 容 器 本 身 被 销毁 ， 数 据 也 将 销毁 。 尽 管 
如 此 ， 这 样 的 函数 属于 特例 ， 而 不 是 惯例 。 


Things to Remember 


。 避免 返回 对 象 内 部 构件 的 句柄 (引用 ， 指 针 ， 或 迭代 器 ) 。 这 样 会 提高 封装 性 ， 帮 助 
const AX A RAU Œ cosnt 效果 ， 并 将 空 基 句柄 产生 的 可 能 性 降 到 最 低 


Item 29: 争取 异常 安全 (exception-safe) 的 代码 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


异常 安全 (Exception safety) 有 点 像 怀 孕 (pregnancy) ...... 但 是 ， 请 把 这 个 想法 先 控 制 一 
会 儿 。 我 们 还 不 能 真正 地 议论 生育 (reproduction) ， 直 到 我 们 排除 万 难 渡 过 求爱 时 期 
(courtship) 。 (此 段 作者 使 用 的 3 个 词 均 有 双关 含义 ，pregnancy 也 可 理解 为 富有 意义 ， 
reproduction 也 可 理解 为 再 现 ， 再 生 ，courtship 也 可 理解 为 争取 ， 谋 求 。 为 了 与 后 面 的 译文 
对 应 ， 故 按照 现在 的 译 法 。 一 一 译 者 注 ) 


假设 我 们 有 一 个 类 ， 代 表 带 有 背景 图 像 的 GUI 菜单 。 这 个 类 被 设计 成 在 多 线程 环境 中 使 用 ， 
所 以 它 有 一 个 用 于 并 行 控制 (concurrency control) 的 互 斥 体 (mutex) 


class PrettyMenu { 


public: 
void changeBackground(std::istream& imgSrc); // change background 
TN: // image 
private: 
Mutex mutex; // mutex for this object 
Image *bgImage; // current background image 
int imageChanges; // # of times image has been changed 
}; 
考虑 这 个 PrettyMenu 的 changeBackground EN 2X AY PT BE 
void PrettyMenu: :changeBackground(std::istream& imgSrc) 
{ 
lock(&mutex) ; // acquire mutex (as in Item 14) 
delete bgImage; // get rid of old background 
++imageChanges; // update image change count 
bgImage = new Image(imgSrc); // install new background 
unlock(&mutex) ; // release mutex 
} 
从 异常 安全 的 观点 看 ， 这 个 图 数 烂 到 了 极点 。 异 常安 全 有 两 条 要 求 ， 而 这 里 全 都 没有 满足 。 


当 一 个 异常 被 抛 出 ， 异 常安 全 的 辑 数 应 该 : 


。 没有 资源 泄露 。 上 面 的 代码 没有 通过 这 个 测试 ， 因 为 如 果 "new Image(imgSrc)" 表达 式 产 
生 一 个 异常 ， 对 unlock 的 调用 就 永远 不 会 执行 ， 而 那个 互 斥 体 也 将 被 永远 挂 起 。 


。 不 允许 数据 结构 恶化 。 如 果 "new Image(imgSrc)" WKH, bglmage 被 遗留 下 来 指向 
一 个 被 删除 对 象 。 另 外， 尽管 并 没有 将 一 张 新 的 图 像 设 置 到 位 ，imageChanges 也 已 经 
被 增加 。 (在 另 一 方面 ， 旧 的 图 像 被 明确 地 删除 ， 所 以 我 料想 你 会 争辩 说 图 像 已 经 被 “ 改 
gee 


规避 资源 泄露 问题 比较 容易 ， 因 为 ltem 13 解释 了 如 何 使 用 对 象 管理 资源 ， 而 ltem 14 又 引进 
T Lock 类 作为 一 种 时 尚 的 确保 互 斥 体 被 释放 的 方法 : 


void PrettyMenu: :changeBackground(std::istream& imgSrc) 


{ 
Lock ml(&mutex); // from Item 14: acquire mutex and 
// ensure its later release 
delete bgImage; 
++imageChanges; 
bgImage = new Image(imgSrc); 


KFIR Lock 这 样 的 资源 管理 类 的 最 好 的 事情 之 一 是 它们 通常 会 使 函数 交 短 。 看 到 对 unlock 
的 调用 不 再 需要 了 吗 ? 作为 一 个 一 般 的 规则 ， 更 少 的 代码 就 是 更 好 的 代码 。 因 为 在 改变 的 时 
候 这 样 可 以 较 少 误 入 歧途 并 较 少 产生 误解 。 


随 着 资源 泄露 被 我 们 甩 在 身后 ， 我 们 可 以 把 我 们 的 注意 力 集中 到 数据 结构 恶化 。 在 这 里 我 们 
有 一 个 选择 ， 但 是 在 我 们 能 选择 之 前 ， 我 们 必须 先 面 对 定义 我 们 的 选择 的 术语 。 


ply, 
iP 


SWRA R MSM RIES : 


安 
。 辑 数 提供 基本 保证 (the basic guarantee) ， 人 允诺 如 果 一 个 异常 被 抛 出 ， 程 序 中 剩 下 的 每 
一 件 东 西 都 处 于 合法 状态 。 没 有 对 象 或 数据 结构 被 破 十， 而且 所 有 的 对 象 都 处 于 内 部 调 
和 状态 (所 有 的 类 不 变量 都 被 满足 ) 。 然 而 ， 程 序 的 精确 状态 可 能 是 不 可 预期 的 。 例 
如 ， 我 们 可 以 重 写 changeBackground， 以 致 于 如 果 一 个 异常 被 抛 出 ，PrettyMenu 对 象 
可 以 继续 保留 原来 的 背景 图 像 ， 或 者 它 可 以 持 有 某 些 缺 省 的 背景 图 像 ， 但 是 客户 无 法 预 
知 到 底 是 哪 一 个 。 (为 了 查 明 这 一 点 ， 他 们 大 概 必须 调用 某 个 可 以 告诉 他 们 当前 背景 图 
RETA AR. ) 


。 AHH ARIE (the strong guarantee) ， 人 允诺 如 果 一 个 异常 被 抛 出 ， 程 序 的 状态 不 
会 发 生变 化 。 调 用 这 样 的 函数 在 感觉 上 是 极其 微弱 的 ， 如 果 它 们 成 功 了 ， 它 们 就 完全 成 
功 ， 如 果 它 们 失败 了 ， 程 序 的 状态 就 像 它们 从 没有 被 调用 过 一 样 。 


与 提供 强力 保证 的 函数 一 起 工作 比 与 只 提供 基本 保证 的 酌 数 一 起 工作 更 加 容易 ， 因 为 调 
用 提供 强力 保证 的 画 数 之 后 ， 仅 有 两 种 可 能 的 程序 状态 : 像 预期 一 样 成 功 执行 了 酚 数 ， 
或 者 继续 保持 函数 被 调用 时 当时 的 状态 。 与 之 相 比 ， 如 果 调 用 只 提供 基本 保证 的 画 数 引 
发 了 异常 ， 程 序 可 能 存在 于 任何 合法 的 状态 。 


。 辑 数 提供 不 抛 出 保证 (the nothrow guarantee) ， 人 允诺 决 不 抛 出 有 异常， 因为 它们 只 做 它 
们 答应 要 做 的 。 所 有 对 内 建 类 型 (例如 ，ints， 指 针 ， 等 等 ) 的 操作 都 是 不 抛 出 
(nothrow) 的 (也 就 是 说 ， 提 供 不 抛 出 保证 ) 。 这 是 异常 安全 代码 中 必 不 可 少 的 基础 构 
件 。 


假定 一 个 带 有 空 的 异常 规格 (exception specification) 的 函数 是 不 抛 出 的 似乎 是 合理 
的 ， 但 这 不 一 定 正 确 的 。 例 如 ， 考 虑 这 个 函数 : 


int doSomething() throw(); // note empty exception spec. 


这 并 不 是 说 doSomething 永远 不 会 抛 出 异常 ; 而 是 说 如 果 doSomething 抛 出 一 个 异常 ， 
它 就 是 一 个 严重 的 错误 ， 应 该 调用 unexpected HWA [1]。 实 际 上 ，doSomething 可 能 根 
本 不 提供 任何 异常 保证 。 一 个 函数 的 声明 〈 如 果 有 的 话 ， 也 包括 它 的 异常 规格 
(exception specification) ) 不 能 告诉 你 一 个 范 数 是 否 正确 ， 是 否 可 移植 ， 或 是 否 高 
效 ， 而 且 ， 即 便 有 ， 它 也 不 能 告诉 你 它 会 提供 哪 一 种 异常 安全 保证 。 所 有 这 些 特性 都 由 
函数 的 实现 决定 ， 而 不 是 它 的 声明 能 决定 的 。 


[1] 关于 unexpected 函数 的 资料 ， 可 以 求助 于 你 中 意 的 搜索 引擎 或 包罗 万 象 的 C++ 课 
本 。 (你 或 许 有 幸 搜 到 set_unexpected， 这 个 函数 用 于 指定 unexpected HR. ) 


异常 安全 画 数 必须 提供 上 述 三 种 保证 中 的 一 种 。 如 果 它 没有 提供 ， 它 就 不 是 异常 安全 的 。 于 
是 ， 选 择 就 在 于 决定 你 写 的 每 一 个 画 数 究竟 要 提供 哪 种 保证 。 除 非 要 久 理 遗留 下 来 的 非 异常 
安全 的 代码 (A ltem 稍 后 我 们 要 讨论 这 个 问题 ) ， 只 有 当 你 的 最 高 明 的 需求 分 析 团 队 为 你 的 
应 用 程序 识别 出 的 一 项 需求 就 是 泄漏 资源 以 及 运行 于 被 破坏 的 数据 结构 之 上 时 ， 不 提供 异常 
安全 保证 才能 成 为 一 个 选项 。 


作为 一 个 一 般 性 的 规则 ， 你 应 该 提供 实际 可 达到 的 最 强力 的 保证 。 从 异常 安全 的 观点 看 ， 不 
抛 出 的 函数 (nothrow functions) 是 极 好 的 ， 但 是 在 C++ 的 C 部 分 之 外 部 不 调用 可 能 抛 出 异 
常 的 函数 简直 就 是 寸步 难 行 。 使 用 动态 分 配 内 存 的 任何 东西 (例如 ， 所 有 的 STL 容器 ) WR 
不 能 找到 足够 的 内 存 来 满足 一 个 请 求 (参见 ltem 49) ， 在 典型 情况 下 ， 它 就 会 抛 出 一 个 
bad_alloc 异常 。 只 要 你 能 做 到 就 提供 不 抛 出 保证 ， 但 是 对 于 大 多 数 函 数 ， 选 择 是 在 基本 的 保 
证 和 强力 的 保证 之 间 的 。 


在 changeBackground 的 情况 下 ， 提 供 差不多 的 强力 保证 并 不 困难 。 首 先 ， 我 们 将 
PrettyMenu 的 bglmage 数据 成 员 的 类 型 从 一 个 内 建 的 Image* 指针 改变 为 Item 13 中 描述 的 
智能 资源 管理 指针 中 的 一 种 。 坦 白地 讲 ， 在 预防 资源 泄漏 的 基本 原则 上 ， 这 完全 是 一 个 好 主 
意 。 它 帮助 我 们 提供 强大 的 异常 安全 保证 的 事实 进一步 加 强 了 ltem 13 的 论点 一 一 使 用 对 象 

(诸如 智能 指针 ) 管理 资源 是 良好 设计 的 基础 。 在 下 面 的 代码 中 ， 我 展示 了 tr1::shared_ptr 
的 使 用 ， 因 为 当 进 行 通常 的 拷贝 时 它 的 更 符合 直觉 的 行为 使 得 它 比 auto_ptr 更 可 取 。 


第 二 ， 我 们 重新 排列 changeBackground 中 的 语句 ， 以 致 于 直到 图 像 发 生变 化 ， 才 增加 
imageChanges。 这 是 一 个 很 好 的 策略 一 一 直到 某 件 事情 真正 发 生 了 ， 再 改变 一 个 对 象 的 状态 
来 表示 某 事 已 经 发 生 。 


这 就 是 修改 之 后 的 代码 : 


class PrettyMenu { 
std: :tr1::shared_ptr<Image> bgImage; 
ee 
void PrettyMenu: :changeBackground(std::istream& imgSrc) 
Lock ml(&mutex); 
bgImage.reset(new Image(imgSrc)); // replace bgImage's internal 
// pointer with the result of the 


// “new Image" expression 
++imageChanges; 


注意 这 里 不 再 需要 手动 删除 旧 的 图 像 ， 因 为 在 智能 指针 内 部 已 经 被 处 理 了 。 此 外 ， 只 有 当 新 
的 图 像 被 成 功 创建 了 删除 行为 才 会 发 生 。 更 准确 地 说 ， 只 有 当 tr1::shared_ptr::reset 函数 的 参 
数 ("new Image(imgSrc)" 的 结果 ) 被 成 功 创建 了 ， 这 个 函数 才 会 被 调用 。 只 有 在 对 reset 的 
调用 的 内 部 才 会 使 用 delete， 所 以 如 果 这 个 画 数 从 来 不 便 进 入 ，delete 就 从 来 不 便 使 用 。 同 
样 请 注意 一 个 管理 资源 (动态 分 配 的 Image) 的 对 象 (tr1::shared_ptr) 的 使 用 再 次 缩短 了 
changeBackground 的 长 度 。 


正如 我 所 说 的 ， 这 两 处 改动 差不多 有 能 力 使 changeBackground 提供 强力 异常 安全 保证 。 美 
中 不 足 的 是 什么 呢 ? 参数 imgSrc。 如 果 Image 的 构造 画 数 抛 出 一 个 异常 ， 输 入 流 (input 
stream) 的 读 标 记 (read marker) 可 能 已 经 被 移动 ， 而 这 样 的 移动 就 成 为 对 程序 的 其 它 部 分 
来 说 可 见 的 一 个 状态 的 变化 。 直 到 changeBackground 着 手 解决 这 个 问题 之 前 ， 它 只 能 提供 
基本 异常 安全 保证 。 


无 论 如 何 ， 让 我 们 把 它 放 在 一 边 ， 并 且 依 然 假装 changeBackground 可 以 提供 强力 保证 。 
(我 相信 你 至 少 能 用 一 种 方法 做 到 这 一 点 ， 或 许可 以 通过 将 它 的 参数 从 一 个 istream 改变 到 包 
含 图 像 数 据 的 文件 的 文件 名 。) 有 一 种 通常 的 设计 策略 可 以 有 代表 性 地 产生 强力 保证 ， 而 且 
熟悉 它 是 非常 必要 的 。 这 个 策略 被 称 为 "copy and swap"。 它 的 原理 很 简单 。 先 做 出 一 个 你 要 
改变 的 对 象 的 拷贝 ， 然 后 在 这 个 拷贝 上 做 出 全 部 所 需 的 改变 。 如 果 改 变 过 程 中 的 某 些 操作 抛 
出 了 异常 ， 最 初 的 对 象 保持 不 变 。 在 所 有 的 改变 完全 成 功 之 后 ， 将 被 改变 的 对 象 和 最 初 的 对 
象 在 一 个 不 会 抛 出 异常 的 操作 中 进行 交换 。 

这 通常 通过 下 面 的 方法 实现 : 将 每 一 个 对 象 中 的 全 部 数据 从 “真正 的 ”对象 中 放 入 到 一 个 单独 的 
实现 对 象 中 ， 然 后 将 一 个 指向 实现 对 象 的 指针 交 给 真正 对 象 。 这 通常 被 称 为 "pimpl idiom", 
Item 31 描述 了 它 的 一 些 细 节 。 对 于 PrettyMenu 来 说 ， 它 一 般 就 像 这 样 : 


struct PMImpl { // PMImpl = "PrettyMenu 
std::tri::shared_ptr<Image> bgImage; // Impl."; see below for 
int imageChanges; // why it's a struct 


}; 
class PrettyMenu { 
private: 


Mutex mutex; 
std::tri::shared_ptr<PMImpl> pImp1; 


J; 
void PrettyMenu: :changeBackground(std::istream& imgSrc) 
: using std::swap; // see Item 25 
Lock ml(&mutex); // acquire the mutex 
std::tri::shared_ptr<PMImp1> // copy obj. data 
pNew(new PMImp1(*pImp1l)); 
pNew->bgImage.reset(new Image(imgSrc)); // modify the copy 


++pNew->imageChanges; 


swap(pImpl, pNew); ie A the oy 
ata into place 


} // release the mutex 


在 这 个 例子 中 ， 我 选择 将 PMimpl 做 成 一 个 结构 体 ， 而 不 是 类 ， 因 为 通过 让 plmpl Æ private 
就 可 以 确保 PrettyMenu 数据 的 封装 。 将 PMImpl 做 成 一 个 类 虽然 有 些 不 那么 方便 ， 却 没有 增 
加 什么 好 处 。 〈 这 也 会 使 有 面向 对 象 洁癖 者 走投无路 。) 如 果 你 愿意 ，PMImpl TAREE 

PrettyMenu 内 部 ， 像 这 样 的 打包 问题 与 我 们 这 里 所 关心 的 写 异 常安 全 的 代码 的 问题 没有 什么 


copy-and-swap 策略 是 一 种 全 面 改 变 或 丝毫 不 变 一 个 对 象 的 状态 的 极 好 的 方法 ， 但 是 ， 在 通 
常情 况 下 ， 它 不 能 保证 全 部 函数 都 是 强力 异常 安全 的 。 为 了 弄 清 原因 ， 考 虑 一 
changeBackground 的 抽象 化 身 一 一 someFunc， 它 使 用 了 copy-and-swap， 但 是 它 包 含 了 对 
另外 两 个 函数 (f1 和 f2) 的 调用 : 


void someFunc() 
{ 

aO 

f2(); 


// make copy of local state 


// swap modified state into place 


(RAR, WR f1 或 从 低 于 强力 异常 安全 ，someFunc 就 很 难 成 为 强力 异常 安全 的 。 例 如 ， 假 
设 f1 信 提 供 基本 保证 。 为 了 让 someFunc 提供 强力 保证 ， 它 必须 写 代 码 在 调用 f1 之 前 测定 整 
个 程序 的 状态 ， 并 捕捉 来 自 f1 的 所 有 蜡 常 ， 然 后 恢复 到 最 初 的 状态 。 


即使 f 和 f2 都 是 强力 异常 安全 的 ， 事 情 也 好 不 到 哪 去 。 如 果 f1 运行 完成 ， 程 序 的 状态 已 经 
发 生 了 毫 无 疑问 的 变化 ， 所 以 如 果 随 后 f2 抛 出 一 个 异常 ， 即 使 和 2 没有 改变 任何 东西 ， 程 序 的 
状态 也 已 经 和 调用 someFunc 时 不 同 。 


PREF RIERA. REKU xt eK ARCHER (例如 ，someFunc 仅仅 影响 调用 它 的 那个 
对 象 的 状态 ) ， 它 提供 强力 保证 就 相对 容易 。 当 函数 的 副作用 影响 了 非 局 部 数据 ， 它 就 会 困 
难得 多 。 例 如 ， 如 果 调 用 f1 的 副作用 是 改变 数据 库 ， 让 someFunc 成 为 强力 异常 安全 就 非常 
困难 。 一 般 情况 下 ， 没 有 办 法 撤销 已 经 提交 的 数据 库 变 化 ， 其 他 数据 库 客户 可 能 已 经 看 见 了 
数据 库 的 新 状态 。 


类 似 这 样 的 问题 会 阻止 你 为 画 数 提供 强力 保证 ， 即 使 你 希望 去 做 。 另 一 个 问题 是 效率 。copy- 
and-swap 的 要 点 是 这 样 一 个 想法 : 改变 一 个 对 象 的 数据 的 拷贝 ， 然 后 在 一 个 不 会 抛 出 异常 的 
操作 中 将 被 改变 的 数据 和 原始 数据 进行 交换 。 这 就 需要 做 出 每 一 个 要 改变 的 对 象 的 拷贝 ， 这 
可 能 会 用 到 你 不 能 或 不 情愿 动用 的 时 间 和 空间 。 强 力 保证 是 非常 值得 的 ， 当 它 可 用 时 你 应 该 
提供 它 ， 除 非 在 它 不 能 100% 可 用 的 时 候 。 


当 它 不 可 用 时 ， 你 就 必须 提供 基本 保证 。 在 实践 中 ， 你 可 能 会 发 现 你 能 为 某 些 函数 提供 强力 
保证 ， 但 是 效率 和 复杂 度 的 成 本 使 得 它 难 以 支持 大 量 的 其 它 事 数 。 无 论 何 时 ， 只 要 你 作出 过 
一 个 提供 强力 保证 的 合理 的 成 果 ， 就 没有 人 会 因为 你 仅仅 提供 了 基本 保证 而 站 在 批评 你 的 立 
场 上 。 对 于 很 多 本 数 来 说 ， 基 本 保证 是 一 个 完全 合理 的 选择 。 


如 果 你 写 了 一 个 根本 没有 提供 异常 安全 保证 的 函数 ， 事 情 就 不 同 了 ， 因 为 在 这 一 点 上 有 罪 推 
定 是 合情合理 的 ， 直 到 你 证 明 自 己 是 清白 的 。 你 应 该 写 出 异常 安全 的 代码 。 除 非 你 能 做 出 有 
说 服 力 的 答辩 。 请 再 次 考虑 someFunc 的 实现 ， 它 调用 函数 f1 和 全。 假设 全 根本 没有 提 
供 异 常安 全 保证 ， 甚 至 没有 基本 保证 。 这 就 意味 着 如 果 f2 发 生 一 个 异常 ， 程 序 可 能 会 在 f2 内 
部 泄漏 资源 。 这 也 意味 着 人 2 可 能 会 恶化 数据 结构 ， 例 如 ， 已 排序 数组 可 能 不 再 排序 ， 一 个 正 
在 从 一 个 数据 结构 传送 到 另 一 个 数据 结构 去 的 对 象 可 能 丢失 ， 等 等 。 没 有 任何 办 法 可 以 让 
someFunc 能 弥补 这 些 问 题 。 如 果 someFunc 调用 的 函数 不 提供 异常 安全 保证 ，someFunc 
本 身 就 不 能 提供 任何 保证 。 


请 允许 我 回 到 怀孕 。 一 个 女性 或 者 怀孕 或 者 没有 。 局 部 怀孕 是 绝 不 可 能 的 。 与 此 相似 ， 一 个 
软件 或 者 是 异常 安全 的 或 者 不 是 。 没 有 像 一 个 局 部 异常 安全 的 系统 这 样 的 东西 。 一 个 系统 即 
使 只 有 一 个 函数 不 是 异常 安全 的 ， 那 么 系统 作为 一 个 整体 就 不 是 异常 安全 的 ， 因 为 调用 那个 
函数 可 能 发 生 港 漏 资 源 和 悉 化 数据 结构 。 不 幸 的 是 ， 很 多 C++ 的 遗留 代码 在 写 的 时 候 没有 留 
意 异 常安 全 ， 所 以 现在 的 很 多 系统 都 不 是 异常 安全 的 。 它 们 混合 了 用 非 异 常安 全 (exception- 
unsafe) 的 方式 书写 的 代码 。 


没有 理由 让 事情 的 这 种 状态 永远 持续 下 去 。 当 书写 新 的 代码 或 改变 现存 代码 时 ， 要 仔细 考虑 
如 何 使 它 异 常安 全 。 以 使 用 对 象 管理 资源 开始 。 (还 是 参见 ltem 13。) 这 样 可 以 防止 资源 泄 
漏 。 接 下 来 ， 决 定 三 种 异常 安全 保证 中 的 哪 一 种 是 你 实际 上 能 够 为 你 写 的 每 一 个 函数 提供 的 
最 强 的 保证 ， 只 有 当 你 不 调用 遗留 代码 就 别 无 选择 的 时 候 ， 才 能 满足 于 没有 保证 。 既 是 为 你 
的 范 数 的 客户 也 是 为 了 将 来 的 维 扩 人员， 文档 化 你 的 决定 。 一 个 画 数 的 异常 安全 保证 是 它 的 
接口 的 可 见 部 分 ， 所 以 你 应 该 特意 选择 它 ， 就 像 你 特意 选择 一 个 函数 接口 的 其 它 方面 。 


四 十 年 前 ， 到 处 都 是 goto 的 代码 被 苯 为 最 佳 实践 。 现 在 我 们 为 书写 结构 化 控制 流程 而 奋斗 。 
二 十 年 前 ， 全 局 可 访问 数据 被 尊 为 最 佳 实践 。 现 在 我 们 为 封装 数据 而 奋斗 ， 十 年 以 前 ， 写 轴 
数 时 不 必 考 虑 异常 的 影响 被 苯 为 最 佳 实践 。 现 在 我 们 为 写 异 常安 全 的 代码 而 奋斗 。 


时 光 在 流逝 。 我 们 生活 着 。 我 们 学 习 着 。 
Things to Remember 


。 即使 当 录 常 被 抛 出 时 ， 异 常安 全 的 函数 不 会 泄露 资源 ， 也 不 允许 数据 结构 被 恶化 。 这 桩 
的 函数 提供 基本 的 ， 强 力 的 ， 或 者 不 抛 出 保证 。 


。 强力 保证 经 常 可 以 通过 copy-and-swap 被 突现， 但 是 强力 保证 并 非 对 所 有 函数 都 可 用 。 
。 一 个 函数 通常 能 提供 的 保证 不 会 强 于 他 所 调用 的 函数 中 最 弱 的 保证 。 


Item 30: 理解 inline 化 的 介入 和 排除 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


inline BAX -多么 棒 的 主意 啊 ! 它们 看 起 来 像 琅 数 ， 它 们 产生 的 效果 也 像 画 数 ， 它 们 在 各 方 
面 都 比 宏 好 得 太 多 太 多 (参见 ltem 2) ， 而 你 却 可 以 在 调用 它们 时 不 招致 男 数 调 用 的 成 本 。 
你 还 有 什么 更 多 的 要 求 呢 ? 





实际 上 你 得 到 的 可 能 比 你 想 的 更 多 ， 因 为 避免 函数 调用 的 成 本 只 是 故事 的 一 部 分 。 在 典型 情 
况 下 ， 编 译 器 的 优化 是 为 了 一 段 连续 的 没有 图 数 调用 的 代码 设计 的 ， 所 以 当 你 inline 化 一 个 函 
数 ， 你 可 能 就 使 得 编译 器 能 够 对 男 数 体 实行 上 下 文 相 关 的 特殊 优化 。 大 多 数 编译 器 都 不 会 对 
"outlined" 函数 调用 实行 这 样 的 优化 。 


然而 ， 在 编程 中 ， 就 像 在 生活 中 ， 没 有 免费 午餐 ， 而 inline 函数 也 不 例外 。 一 个 inline HRA 
后 的 思想 是 用 函数 本 体 代 蔡 每 一 处 对 这 个 函数 的 调用 ， 而 且 不 必 拿 着 统计 表 中 的 Ph.D. 就 可 

以 看 出 这 样 可 能 会 增加 你 的 目标 代码 的 大 小 。 在 有 限 内 存 的 机 器 上 ， 过 分 热衷 于 inline 化 会 使 
得 程序 对 于 可 用 空间 来 说 过 于 上 庞大。 即使 使 用 了 虚拟 内 存 ，inline 引起 的 代码 膨胀 也 会 导致 附 
加 的 分 页 调度 ， 减 少 指令 缓存 命中 率 ， 以 及 随 之 而 来 的 性 能 损失 。 


在 另 一 方面 ， 如 果 一 个 inline 画 数 本 体 很 短 ， 为 函数 本 体 生 成 的 代码 可 能 比 为 一 个 画 数 调用 生 
成 的 代码 还 要 小 。 如 果 是 这 种 情况 ，inline 化 这 个 函数 可 以 实际 上 导致 更 小 的 目标 代码 和 更 高 
DFE Fa | 

记 住 ，inline 是 向 编译 器 发 出 的 一 个 请 求 ， 而 不 是 一 个 命令 。 这 个 请 求 能 够 以 显 式 的 或 隐 式 的 
方式 提出 。 隐 式 的 方法 就 是 在 一 个 类 定义 的 内 部 定义 一 个 函数 : 


class Person { 


public: 
int age() const { return theAge; } // an implicit inline request: age is 
TE // defined in a class definition 
private: 
int theAge; 
}; 


RN RAE eM AR, (Be Item 46 解释 了 友 元 函数 也 能 被 定义 在 类 的 内 部 ， 如 果 它 们 
在 那里 ， 它 们 也 被 隐 式 地 声明 为 inline。 


显 式 地 声明 一 个 inline 本 数 的 方法 是 在 它 的 声明 之 前 加 上 inline 关键 字 。 例 如 ， 以 下 就 是 标准 
max 模板 (来 自 <algorithm>) 经 常用 到 的 的 实现 方法 : 


template<typename T> // an explicit inline 
inline const T& std::max(const T& a, const T& b) // request: std::max is 
{ returna<b?b: a; } // preceded by "inline" 


max 是 一 个 模板 的 事实 引出 一 个 观察 结论 inline 函数 和 模板 一 般 都 是 定义 在 头 文件 中 的 。 这 
就 使 得 一 些 程序 员 得 出 结论 断定 函数 模板 必须 是 inline。 这 个 结论 是 非法 的 而 且 有 潜在 的 危 
害 ， 所 以 它 值得 我 们 考察 一 下 。 


inline 函数 一 般 必 须 在 头 文 件 内 ， 因 为 大 多 数 构 建 环境 在 编译 期 间 进 行 inline 化 。 为 了 用 被 调 
用 函数 的 画 数 本 体 蔡 换 一 个 画 数 调用 ， 编 译 器 必须 知道 画 数 看 起 来 像 什 么 样子 。 (有 一 些 构 
建 环境 可 以 在 连接 期 间 进行 inline 化 ， 还 有 少数 几 个 一 一 比如 ， 基 于 .NET Common 
Language Infrastructure (CLI) 的 控制 环境 一 一 居然 能 在 运行 时 inline 化 。 然 而， 这 些 环境 都 
是 例外 ， 并 非 规则 。inline 化 在 大 多 数 C++ 程序 中 是 一 个 编译 时 行为 。) 








模板 一 般 在 头 文件 内 ， 因 为 编译 器 需要 知道 一 个 模板 看 起 来 像 什么 以 便 用 到 它 时 对 它 进行 实 
例 化 。 (同样 ， 也 不 是 全 部 如 此 。 一 些 构 建 环境 可 以 在 连接 期 间 进 行 模板 实例 化 。 然 而 ， 编 
译 期 实例 化 更 为 普通 。) 


模板 实例 化 与 inline 化 无 关 。 如 果 你 写 了 一 个 模板 ， 而 且 你 认为 所 有 从 这 个 模板 实例 化 出 来 的 
函数 都 应 该 是 inline 的 ， 那 么 就 声明 这 个 模板 为 inline， 这 就 是 上 面 的 std::max 的 实现 被 做 的 
事情 。 但 是 如 果 你 为 没有 理由 要 inline 化 的 函数 写 了 一 个 模板 ， 就 要 避免 声明 这 个 模板 为 
inline (无 论 显 式 的 还 是 隐 式 的 ) 。inline 化 是 有 成 本 的 ， 而 且 你 不 希望 在 毫 无 预见 的 情况 下 
遭遇 它们 。 我 们 已 经 说 到 inline 化 是 如 何 引 起 代码 膨胀 的 (这 对 于 模板 作者 来 说 是 极为 重要 的 
一 个 考虑 事项 一 一 参见 ltem 44) ， 但 是 ， 还 有 其 它 的 成 本 ， 过 一 会 儿 我 们 再 讨论 。 





在 做 这 件 事 之 前 ， 我 们 先 来 完成 对 这 个 结论 的 考察 inline 是 一 个 编译 器 可 能 忽略 的 请 求 。 大 
多 数 编译 器 拒绝 它们 认为 太 复杂 的 inline HR 〈 例 如， 那些 包含 循环 或 者 递归 的 ) ， 而 且 ， 除 
了 最 细碎 的 以 外 的 全 部 虚拟 函数 的 调用 都 不 会 被 inline 化 。 不 应 该 对 这 后 一 个 结论 感到 惊讶 。 
虚拟 意味 着 “等 待 ， 直 到 运行 时 才能 断定 哪 一 个 画 数 被 调用 ”， 而 inline 意味 着 “执行 之 前 ， 用 被 
调用 本 数 取代 调用 的 地 方 "， 如 果 编 译 器 不 知道 哪 一 个 函数 将 被 调用 ， 你 很 难 责 备 它们 拒绝 
inline 163% SRAM, 


所 有 这 些 加 在 一 起 ， 得 出 : 一 个 被 指定 的 inline 函数 是 否 能 真 的 被 inline 化， 取决 于 你 所 使 用 
的 构建 环境 一 一 主要 是 编译 器 。 幸 运 的 是 ， 大 多 数 编译 器 都 有 一 个 诊断 层次 ， 在 它们 不 能 
inline 化 一 个 你 提出 的 函数 时 ， 会 导致 一 个 警告 (参见 ltem 53) 。 


有 时 候 ， 即 使 当 编译 器 完全 心甘情愿 地 inline 化 一 个 函数 ， 他 们 还 是 会 为 这 个 inline KHAR 
函数 本 体 。 例 如 ， 如 果 你 的 程序 要 持 有 一 个 inline 画 数 的 地 址 ， 编 译 器 必须 为 它 生 成 一 个 
outlined 函数 本 体 。 他 们 怎么 能 生成 一 个 指向 根本 不 存在 的 画 数 的 指针 呢 ?再 加 上 ， 编 译 器 一 
般 不 会 对 通过 函数 指针 的 调用 进行 inline 化 ， 这 就 意味 着 ， 对 一 个 inline 函数 的 调用 可 能 被 也 
可 能 不 被 inline 化， 依赖 于 这 个 调用 是 如 何 做 成 的 : 


inline void f() {...} // assume compilers are willing to inline calls to f 


void (*pf)() = f; // pf points to f 
F(); // this call will be inlined, because it's a "normal" call 
pf(); // this call probably won't be, because it's through 


// a function pointer 


BEEMMESA HAHAHA, ZX inline 化 的 inline 函数 的 幽灵 也 会 时 不 时 地 拜访 
你 ， 因 为 程序 员 并 不 必然 是 函数 指针 的 唯一 需求 者 。 有 时 候 编译 器 会 生成 构造 画 数 和 析 构 函 
数 的 out-of-line 拷贝 ， 以 便 它 们 能 得 到 指向 这 些 函 数 的 指针 ， 在 对 数组 中 的 对 象 进行 构造 和 
析 构 时 使 用 。 


事实 上 ， 构 造 男 数 和 析 构 函数 对 于 inline 化 来 说 经 常 是 一 个 比 你 在 不 经 意 的 检查 中 所 能 显示 出 
来 的 更 加 糟糕 的 候 先 者。 例如， 考虑 下 面 这 个 类 Derived 的 构造 画 数 : 


class Base { 
public: 


private: 
std::string bm1, bm2; // base members 1 and 2 


3; 
class Derived: public Base { 


public: 
Derived() {} // Derived's ctor is empty — or is it? 


private: 
std::string dm1, dm2, dm3; // derived members 1-3 


J; 


KP HEWRALAR—T inline 化 的 极 好 的 候选 者 ， 因 为 它 不 包含 代码 。 但 是 视觉 会 被 欺 
骗 。 

C++ 为 对 象 被 创建 和 被 销毁 时 所 发 生 的 事情 做 出 了 各 种 保证 。 例 如 ， 当 你 使 用 new 时 ， 你 的 
动态 的 被 创建 对 象 会 被 它们 的 构造 画 数 自动 初始 化 ， 而 当 你 使 用 delete。 则 相应 的 析 构 函数 
会 被 调用 。 当 你 创建 一 个 对 象 时 ， 这 个 对 象 的 每 一 个 基 类 和 每 一 个 数据 成 员 都 会 自动 构造 ， 

而 当 一 个 对 象 被 销毁 时 ， 则 发 生 关于 析 构 的 反 向 过 程 。 如 果 在 一 个 对 象 构造 期 间 有 一 个 异常 
被 抛 出 ， 这 个 对 象 已 经 完成 构造 的 任何 部 分 都 被 自动 销毁 。 所 有 这 些 情节 ，C++ 只 说 什么 必 
须发 生 ， 但 没有 说 如 何 发 生 。 那 是 编译 器 的 实现 者 的 事 ， 但 显然 这 些 事情 不 会 自己 发 生 。 在 
你 的 程序 中 必须 有 一 些 代 码 使 这 些 事 发 生 ， 而 这 些 代码 由 编译 器 写 出 的 代码 和 在 编译 期 
间 揪 入 你 的 程序 的 代码 必须 位 于 某 处 。 有 时 它们 最 终 就 位 于 构造 画 数 和 析 构 画 数 中 ， 所 
以 我 们 可 以 设想 实现 为 上 面 那 个 声称 为 空 的 Derived 的 构造 画 数 生成 的 代码 就 相当 于 下 面 这 
样 : 








Derived: :Derived() // conceptual implementation of 


{ // “empty" Derived ctor 

Base: :Base(); // initialize Base part 

try { dmi.std::string::string(); } // try to construct dmi 

catch (...) { // if it throws, 
Base: :~Base(); // destroy base class part and 
throw; // propagate the exception 

} 

try { dm2.std::string::string(); } // try to construct dm2 

catch(...) { // if it throws, 
dmi.std::string::~string(); // destroy dm1, 
Base: :~Base(); // destroy base class part, and 
throw; // propagate the exception 

} 

try { dm3.std::string::string(); } // construct dm3 

catch(...) { // if it throws, 
dm2.std::string::~string(); // destroy dm2, 
dmi.std::string::~string(); // destroy dm1, 
Base: :~Base(); // destroy base class part, and 
throw; // propagate the exception 

} 

} 


这 些 代码 并 不 代表 真正 的 编译 器 所 生成 的 ， 因 为 真正 的 编译 器 会 用 更 复杂 的 方法 处 理 异常 。 
尽管 如 此 ， 它 还 是 准确 地 反映 了 Derived 的 “ 空 ” 攀 造 琅 数 必须 提供 的 行为 。 不 论 一 个 编译 器 的 
异常 多 么 复杂 ，Derived 的 构造 画 数 至 少 必须 调用 它 的 数据 成 员 和 基 类 的 构造 男 数 ， 而 这 些 调 
用 (它们 自己 也 可 能 是 inline 的 ) 会 影响 它 对 于 inline 化 的 吸引 力 。 


同样 的 原因 也 适用 于 Base 的 构造 画 数 ， 所 以 如 果 它 是 inline 的 ， 插 入 它 的 全 部 代码 也 要 插入 
Derived HJ Až 〈 通 过 Derived 的 构造 画 数 对 Base 的 构造 画 数 的 调用 ) 。 而 且 如 果 
string 89 438 Es AU T5 th Z inline 的 ，Derived 的 构造 函数 中 将 增加 五 个 那个 函数 代码 的 找 
贝 ， 分 别 对 应 于 Derived 对 象 中 的 五 个 strings (两 个 继承 的 加 上 三 个 它 自 己 声 明 的 ) 。 也 许 
在 现在 ， 为 什么 说 是 否 inline 化 Derived 的 构造 琅 数 不 是 一 个 不 经 大 脑 的 决定 就 很 清楚 了 。 类 
似 的 考虑 也 适用 于 Derived 的 析 构 函数， 用 同样 的 或 者 不 同 的 方法 ， 必 须 保 证 所 有 被 Derived 
的 构造 画 数 初始 化 的 对 象 被 完全 销毁 。 


库 设 计 者 必须 评估 声明 函数 为 inline 的 影响 ， 因 为 为 库 中 的 客户 可 见 的 inline 函数 提 供 二 进 制 
升级 版 本 是 不 可 能 的 。 换 句 话说， 如 果 f 是 一 个 库 中 的 一 个 inline 函数 ， 库 的 客户 将 函数 ff 的 
本 体 编译 到 他 们 的 应 用 程序 中 。 如 果 一 个 库 的 实现 者 后 来 决定 修改 f 所 有 使 用 了 f 的 客户 都 

必须 重新 编译 。 这 常常 会 全 人 厌烦 。 在 另 一 方面 ， 如 果 f 是 一 个 非 inline 函数 ， 对 ff 的 改变 只 
apn A 这 与 重新 编译 相 比 显然 减轻 了 很 大 的 负担 ， 而 且 ， 如 果 库 中 包含 的 函数 
是 动态 链接 的 ， 这 就 是 一 种 对 于 用 户 来 说 完全 透明 的 方法 。 


为 了 程序 开发 的 目标 ， 在 头脑 中 牢记 这 些 需 要 考虑 的 事项 是 很 重要 的 ， 但 是 从 编码 期 间 的 实 
用 观点 来 看 ， 占 有 支配 地 位 的 事实 是 : 大 多 数 调试 器 会 与 inline 函数 发 生 冲 突 。 这 不 应 该 是 什 
么 重大 的 发 现 。 你 怎么 能 在 一 个 不 在 那里 的 函数 中 设置 断 点 呢 ? 虽然 一 些 构建 环境 设法 支持 
inline 函数 的 调试 ， 多 数 环境 还 是 简单 地 为 调试 构建 取消 了 inline 化 。 


这 就 导出 了 一 个 用 于 决定 哪些 函数 应 该 被 声明 为 inline， 哪 些 不 应 该 的 合乎 逻辑 的 策略 。 最 
初 ， 不 要 inline 任何 东西 ， 或 者 至 少 要 将 你 的 inline 化 的 范围 限制 在 那些 必须 inline 的 (参见 
Item 46) 和 那些 实在 微不足道 的 (就 像 第 135 页 上 的 Person::age) 函数 上 。 通 过 慎重 地 使 
用 inline， 你 可 以 使 调试 器 的 使 用 变 得 容易 ， 但 是 你 也 将 inline 化 放 在 了 它 本 来 应 该 在 的 地 
位 : 作为 一 种 手动 的 优化 。 不 要 忘记 由 经 验 确定 的 80-20 规则 ， 它 宣称 一 个 典型 的 程序 用 
80% 的 时 间 执 行 20% 的 代码 。 这 是 一 个 重要 的 规则 ， 因 为 它 提 醒 你 作为 一 个 软件 开发 者 的 目 
标 是 识别 出 能 全 面 提升 你 的 程序 性 能 的 20% 的 代码 。 你 可 以 inline 或 者 用 其 他 方式 无 限期 地 
调节 你 的 函数 ， 但 除非 你 将 精力 集中 在 正确 的 画 数 上 ， 否 则 就 是 白白 浪费 精力 。 


Things to Remember 


。 将 大 部 分 inline 限制 在 小 的 ， 调 用 频繁 的 函数 上 。 这 使 得 程序 调试 和 二 进 制 升级 更 加 容 
易 ， 最 小 化 潜在 的 代码 膨胀 ， 并 最 大 化 提高 程序 速度 的 几率 。 


。 不 要 公公 因为 函数 模板 出 现在 头 文件 中 ， 就 将 它 声 明 为 inline。 


Item 31: 最 小 化 文件 之 间 的 编译 依赖 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


你 进入 到 你 的 程序 中 ， 并 对 一 个 类 的 实现 进行 了 细微 的 改变 。 提 醒 你 一 下 ， 不 是 类 的 接口 ， 
只 是 实现 ， 仅 仅 是 private 的 东西 。 然 后 你 重建 (rebuild) 这 个 程序 ， 预 计 这 个 任务 应 该 只 花 
费 几 秒 钟 。 毕 竟 只 有 一 个 类 被 改变 。 你 在 Build 上 点 击 或 者 键入 make (或 者 其 它 等 价 行 

为 ) ， 接 着 你 被 惊 呆 了 ， 继 而 被 郁闷 ， 就 像 你 突然 意识 到 整个 世界 都 被 重新 编译 和 连接 ! 当 
这 样 的 事情 发 生 的 时 候 ， 你 不 讨厌 它 吗 ? 


问题 在 于 C++ 没有 做 好 从 实现 中 剥离 接口 的 工作 。 一 个 类 定义 不 仅 指定 了 一 个 类 的 接口 而 且 
有 相当 数量 的 实现 细节 。 例 如 : 


class Person { 
public: 
Person(const std::string& name, const Date& birthday, 
const Address& addr); 
std::string name() const; 
std::string birthDate() const; 
std::string address() const; 


private: 
std::string theName; // implementation detail 
Date theBirthDate; // implementation detail 
Address theAddress; // implementation detail 
J; 


在 这 里 ， 如 果 不 访问 Person 的 实现 使 用 到 的 类 ， 也 就 是 string，Date 和 Address 的 定义 ， 
类 Person 就 无 法 编译 。 这 样 的 定义 一 般 通过 #include 指令 提供 ， 所 以 在 定义 Person 类 的 文 
件 中 ， 你 很 可 能 会 找到 类 似 这 样 的 东西 : 


#include <string> 
#include "date.h" 
#include "address.h" 


不 幸 的 是 ， 这 样 就 建立 了 定义 Person 的 文件 和 这 些 头 文件 之 间 的 编译 依赖 关系 。 如 果 这 些 头 
文件 中 的 一 些 发 生 了 变化 ， 或 者 这 些 头 文件 所 依赖 的 文件 发 生 了 变化 ， 包 合 Person 类 的 文件 
和 使 用 了 Person 的 文件 一 样 必须 重新 编译 ， 这 样 的 层 党 编译 依赖 关系 为 项 目 带 来 数 不 清 的 麻 
Klo 


你 也 许 想 知道 C++ 为 什么 坚持 要 将 一 个 类 的 实现 细节 放 在 类 定义 中 。 例 如 ， 你 为 什么 不 能 这 
样 定义 Person， 单 独 指 定 这 个 类 的 实现 细节 了 呢 ? 


namespace std { 


class string; // forward declaration (an incorrect 
} // one — see below) 
class Date; // forward declaration 
class Address; // forward declaration 


class Person { 
public: 
Person(const std::string& name, const Date& birthday, 
const Address& addr); 
std::string name() const; 
std::string birthDate() const; 
std::string address() const; 


ten 


如 果 这 样 可 行 ， 只 有 在 类 的 接口 发 生变 化 时 ，Person 的 客户 才 必 须 重 新 编译 。 


这 个 主意 有 两 个 问题 。 第 一 个 ，string 不 是 一 个 类 ， 它 是 一 个 typedef (for 
basic_string<char>)。 造 成 的 结果 就 是 ，string 的 前 向 声明 (forward declaration) 是 不 正确 
的 。 正 确 的 前 向 声明 要 复杂 得 多 ， 因 为 它 包 括 另 外 的 模板 。 然 而 ， 这 还 不 是 要 紧 的 ， 因 为 你 
不 应 该 试 着 手动 声明 标准 库 的 部 件 。 作 为 替代 ， 直 接 使 用 适当 的 #includes 并 让 它 去 做 。 标 准 
头 文件 不 太 可 能 成 为 编译 的 瓶颈 ， 特 别 是 在 你 的 构建 环境 允许 你 利用 预 编 译 关 文件 时 。 如 果 
解析 标准 头 文件 真 的 成 为 一 个 问题 。 你 也 许 需 要 改变 你 的 接口 设计 ， 避 免 使 用 导致 不 受 欢 迎 
BY #includes 的 标准 库 部 件 。 


第 二 个 (而 且 更 重要 的 ) 难点 是 前 向 声明 的 每 一 件 东 西 必 须 让 编译 器 在 编译 期 间 知道 它 的 对 
RK). Be: 


int main() 
int x; // define an int 


Person p( params ); // define a Person 


} 


当 编译 器 看 到 x 的 定义 ， 它 们 知道 它们 必须 为 保存 一 个 int 分 配 足 够 的 空间 (一 般 是 在 栈 
上 ) 。 这 没什么 问题 ， 每 一 个 编译 器 都 知道 一 个 int 有 多 大 。 当 编译 器 看 到 p 的 定义 ， 它 们 知 
道 它们 必须 为 一 个 Person 分 配 足够 的 空间 ， 但 是 它们 怎么 推测 出 一 个 Person 对 象 有 多 大 
呢 ? 它们 得 到 这 个 信息 的 唯一 方法 是 参考 这 个 类 的 定义 ， 但 是 如 果 一 个 省 略 了 实现 细节 的 类 
定义 是 合法 的 ， 编 译 器 怎么 知道 要 分 配 多 大 的 空间 呢 ? 

这 个 问题 在 诸如 Smalltalk 和 Java 这 样 的 语言 中 就 不 会 发 生 ， 因 为 ， 在 这 些 语言 中 ， 当 一 个 
类 被 定义 ， 编 译 器 仅仅 为 一 个 指向 一 个 对 象 的 指针 分 配 足 够 的 空间 。 也 就 是 说 ， 它 们 处 理 上 
面 的 代码 就 像 这 些 代码 是 这 样 写 的 : 


int main() 
int x; // define an int 


Person *p; // define a pointer to a Person 


当然 ， 这 是 合法 的 C++， 所 以 你 也 可 以 自己 来 玩 这 种 “将 类 的 实现 隐藏 在 一 个 指针 后 面 " 的 游 
戏 。 对 Person 做 这 件 事 的 一 种 方法 就 是 将 它 分 开 到 两 个 类 中 ， 一 个 仅仅 提供 一 个 接口 ， 另 一 
个 实现 这 个 接口 。 如 果 那 个 实现 类 名 为 Personimpl, Person 就 可 以 如 此 定义 : 


#include <string> // standard library components 
// shouldn't be forward-declared 


#include <memory> // for tri::shared_ptr; see below 
class PersonImpl; // forward decl of Person impl. class 
class Date; // forward decls of classes used in 
class Address; // Person interface 

class Person { 

public: 


Person(const std::string& name, const Date& birthday, 
const Address& addr); 

std::string name() const; 

std::string birthDate() const; 

std::string address() const; 


private: // ptr to implementation; 
std::tri::shared_ptr<PersonImpl> pImpl; // see Item 13 for info on 
}; // std::tri::shared_ptr 


这 样 ， 主 类 (Person) A ‘Personimpl 的 指针 (这 里 是 一 个 

见 ltem 13) 之 外 不 包含 其 它 数 据 成 员 。 这 样 一 个 设计 经 常 被 说 成 是 使 
用 了 pimpl if 法 hana "pointer to sesh er TEXAN, ABS 
针 的 名 字 经 常 是 plmpl, 就 像 上 面 那个 。 





用 这 样 的 设计 ， 使 Person 的 客户 脱离 dates, addresses 和 persons 的 细节 。 这 些 类 的 实现 
可 以 随心 所 欲 地 改变 ， 但 Person 的 客户 却 不 必 重 新 编译 。 另 外 ， 因 为 他 们 看 不 到 Person 的 
实现 细节 ， 客 户 就 不 太 可 能 写 出 以 某 种 方式 依赖 那些 细节 的 代码 。 这 就 是 接口 和 实现 的 真正 

分 离 。 


这 个 分 离 的 关键 就 是 用 对 声明 的 依赖 替代 对 定义 的 依赖 。 这 就 是 最 小 化 编译 依赖 的 精髓 : 只 
要 能 实现 ， 就 让 你 的 头 文件 独立 自足 ， 如 果 不 能 ， 就 依赖 其 它 文件 中 的 声明 ， 而 不 是 定义 。 
其 它 每 一 件 事 都 从 这 个 简单 的 设计 策略 产生 。 所 以 : 


。 当 对 象 的 引用 和 指针 可 以 做 到 时 就 避免 使 用 对 象 。 仅 需 一 个 类 型 的 声明 ， 你 就 可 以 定义 
到 这 个 类 型 的 引用 或 指针 。 而 定义 一 个 类 型 的 对 象 必须 要 存在 这 个 类 型 的 定义 。 


。 只 要 你 能 做 到 ， 就 用 对 类 声明 的 依赖 蔡 代 对 类 定义 的 依赖 。 注 意 你 声明 一 个 使 用 一 
的 酌 数 时 绝对 不 需要 有 这 个 类 的 定义 ， 即 使 这 个 函数 通过 传 值 方式 传递 或 返回 这 个 类 : 


class Date; // class declaration 


Date today(); // fine — no definition 
void clearAppointments(Date d); // of Date is needed 


当然 ， 传 值 通 常 不 是 一 个 好 主意 (参见 Item 20) ， 但 是 如 果 你 发 现 你 自己 因为 某 种 原因 
而 使 用 它 ， 依 然 不 能 为 引入 不 必要 的 编译 依赖 辩解 。 


不 声明 Date 就 可 以 声明 today 和 clearAppointments 的 能 力 可 能 会 令 你 感到 惊奇 ， 但 是 
它 其 实 并 不 像 看 上 去 那么 不 同 寻 常 。 如 果 有 人 调用 这 些 范 数 ， 则 Date 的 定义 必须 在 调用 
之 前 被 看 到 。 为 什么 费心 去 声明 没有 人 调用 的 函数 ， 你 想 知 道 吗 ?很 简 单 。 并 不 是 没有 
人 调用 它们 ， 而 是 并 非 每 个 人 都 要 调用 它们 。 如 果 你 有 一 个 包含 很 多 男 数 声明 的 库 ， 每 
一 个 客户 都 要 调用 每 一 个 范 数 是 不 太 可 能 的 。 通 过 将 提供 类 定义 的 责任 从 你 的 声明 画 数 
的 头 文件 转移 到 客户 的 包含 画 数 调用 的 文件 ， 你 就 消除 了 客户 对 他 们 并 不 真 的 需要 的 类 
型 的 依赖 。 


。 为 声明 和 定义 分 别提 供 头 文件 。 为 了 便于 坚持 上 面 的 指导 方针 ， 头 文件 需要 成 对 出 现 : 
一 个 用 于 声明 ， 另 一 个 用 于 定义 。 当 然 ， 这 些 文件 必须 保持 一 致 。 如 果 一 个 声明 在 一 个 
地 方 被 改变 了 ， 它 必须 在 两 处 都 被 改变 。 得 出 的 结果 是 : 库 的 客户 应 该 总 是 #include 一 
个 声明 文件 ， 而 不 是 自己 前 向 声明 某 些 未 西 ， 而 库 的 作者 应 该 提供 两 个 头 文件 。 例 如 ， 
想 要 声明 today 和 clearAppointments 的 Date 的 客户 不 应 该 像 前 面 展 示 的 那样 手动 前 向 
声明 Date。 更 合适 的 是 ， 它 应 该 #include 适当 的 用 于 声明 的 头 文件 : 


#include "datefwd.h" // header file declaring (but not 
// defining) class Date 


Date today(); // as before 
void clearAppointments(Date d); 


仅 有 声明 的 头 文件 的 名 字 "datefwd.h" 基于 来 自 标准 C++ è (BM Item 54) 的 头 文件 
<iosfwd>。<iosfwd> 包含 iostream 组 件 的 声明 ， 而 它们 相应 的 定义 在 几 个 不 同 的 头 文件 
中 ， 包 括 <sstream>，<streambuf>，<fstream> 和 <iostream>。 


<iosfwd> 在 其 它 方面 也 有 启发 意义 ， 而 且 它 解释 了 本 Item 的 建议 对 于 模板 和 非 模板 一 样 
AM, KE ltem 30 解释 了 在 很 多 构建 环境 中 ， 模 板 定义 的 典型 特征 是 位 于 头 文件 中 ， 但 
有 些 环境 允许 模板 定义 在 非 头 文件 中 ， 所 以 为 模板 提供 一 个 仅 有 声明 的 头 文件 依然 是 有 
意义 的 。<iosfwd> 就 是 一 个 这 样 的 头 文件 。 


C++ 还 提供 了 export 关键 字 人 多 许 将 模板 声明 从 模板 定义 中 分 离 出 来 。 不 幸 的 是 ， 支 持 
export 的 编译 器 非常 少 ， 而 与 export 打交道 的 实际 经 验 就 更 少 了 。 结 果 是 ， 现 在 就 说 
export 在 高 效 C++ 编程 中 扮演 什么 角色 还 为 时 尚 早 。 


像 Person 这 样 的 使 用 pimpl 惯用 法 的 类 经 常 被 称 为 Handle 类 。 为 了 避免 你 对 这 样 的 类 实际 
上 做 什么 事 的 好 奇 心 ， 一 种 方法 是 将 所 有 对 他 们 的 函数 调用 都 转送 给 相应 的 实现 类 ， 而 使 用 
实现 类 来 做 真正 的 工作 。 例 如 ， 这 就 是 两 个 Person 的 成 员 函 数 可 以 被 如 何 实现 的 例子 : 


#include "Person.h" // we're implementing the Person class, 
// so we must #include its class definition 


#include "PersonImpl.h" // we must also #include PersonImpl's class 
// definition, otherwise we couldn't call 
// its member functions; note that 
// PersonImpl has exactly the same 
// member functions as Person — their 
// interfaces are identical 


Person: :Person(const std::string& name, const Date& birthday, 
const Address& addr) 
: pImpl(new PersonImpl(name, birthday, addr) ) 


Ü 
std::string Person::name() const 
{ 
return pImpl->name(); 
} 


注意 Person 的 成 员 画 数 是 如 何 调用 Personimpl 的 成 员 画 数 的 (通过 使 用 new 
Item 16) ， 以 及 Person::name 是 如 何 调用 Personlmpl::name 的 。 这 很 重要 。 使 Person 成 
为 一 个 Handle 类 不 需要 改变 Person 要 做 的 事情 ， 仅 仅 是 改变 了 它 做 事 的 方法 。 


参见 





另 一 个 不 同 于 Handle 类 的 候选 方法 是 使 Person 成 为 一 个 被 叫做 Interface 类 的 特殊 种 类 的 抽 
象 基 类 。 这 样 一 个 类 的 作用 是 为 派生 类 指定 一 个 接口 (参见 ltem 34) 。 结 果 ， 它 的 典型 特征 
是 没有 数据 成 员 ， 没 有 构造 琅 数 ， 有 一 个 虚 析 构 玉 数 (参见 ltem 7) 和 一 组 指定 接口 的 纯 虚 
AR. 


Interface 类 类 似 Java 和 .NET 中 的 Interfaces， 但 是 C++ 并 不 会 为 Interface 类 强加 那些 
Java 和 .NET 为 Interfaces 强加 的 种 种 约束 。 例 如 ，Java 和 .NET 都 不 允许 Interfaces 中 有 
数据 成 员 和 男 数 实现 ， 但 是 C++ 不 禁止 这 些 事情 。C++ 的 巨大 弹性 是 有 用 处 的 。 就 像 Item 
36 解释 的 ， 在 一 个 继承 体系 的 所 有 类 中 非 虚拟 函数 的 实现 应 该 相同 ， 因 此 将 这 样 的 画 数 实现 
为 声明 它们 的 Interface 类 的 一 部 分 就 是 有 意义 的 。 


一 个 Person 的 Interface 类 可 能 就 像 这 样 : 


class Person { 
public: 
virtual ~Person(); 


virtual std::string name() const = 0; 


virtual std::string birthDate() const = 0; 
virtual std::string address() const = 0; 


T 


这 个 类 的 客户 必须 针对 Person 的 指针 或 引用 编程 ， 因 为 实例 化 包含 纯 虚 函数 的 类 是 不 可 能 
的 。 (然而 ， 实 例 化 从 Person 派生 的 类 是 可 能 区 参见 后 面 。) 和 Handle 类 的 客户 一 
样 ， 除 非 Interface 类 的 接口 发 生变 化 ， 否 则 Interface 类 的 客户 不 需要 重新 编译 。 





一 个 Interface 类 的 客户 必须 有 办 法 创建 新 的 对 象 。 他 们 一 般 通 过 调用 一 个 为 “可 以 真正 实例 化 
的 派生 类 ”扮演 构造 画 数 的 角色 的 函数 做 到 这 一 点 的 。 这 样 的 函数 一 般 称 为 factory HR (参见 
Item 13) 或 虚拟 构造 画 数 (virtual constructors) 。 他 们 返回 指向 动态 分 配 的 支持 Interface 
类 的 接口 的 对 象 的 指针 (智能 指针 更 合适 一 一 参见 Item 18) 。 这 样 的 函数 在 Interface 类 内 
部 一 般 声 明 为 static : 





class Person { 


public: 
static std::tr1::shared_ptr<Person> // return a tri::shared ptr to a new 
create(const std::string& name, // Person initialized with the 
const Date& birthday, // given params; see Item 18 for 
const Address& addr); // why a tri::shared_ptr is returned 
3; 
客户 就 像 这 样 使 用 它们 : 


std::string name; 
Date dateOfBirth; 
Address address; 


// create an object supporting the Person interface 
std::tri::shared_ptr<Person> pp(Person::create(name, dateOfBirth, address)); 


std::cout << pp->name() // use the object via the 

<< " was born on " // Person interface 

<< pp->birthDate() 

<< " and now lives at " 

<< pp->address(); 
// the object is automatically 
// deleted when pp goes out of 
// scope — see Item 13 


当然 ， 在 某 些 地 点 ， 必 须 定义 支持 Interface ži OiR HAAA ERIA ERNA. XAT 
有 的 一 切 发 生 的 场合 ， 在 那个 文件 中 所 包含 虚拟 构造 函数 的 实现 之 后 的 地 方 。 例 如 ，lnterface 
类 Person 可 以 有 一 个 提供 了 它 继承 到 的 虚 函 数 的 实现 的 具体 的 派生 类 RealPerson : 


class RealPerson: public Person { 
public: 
RealPerson(const std::string& name, const Date& birthday, 
const Address& addr) 
: theName(name), theBirthDate(birthday), theAddress(addr) 


{} 


virtual ~RealPerson() {} 


std::string name() const; // implementations of these 

std::string birthDate() const; // functions are not shown, but 

std::string address() const; // they are easy to imagine 
private: 


std::string theName; 
Date theBirthDate; 
Address theAddress; 


}; 


对 这 个 特定 的 RealPerson， 写 Person::create 确实 没什么 价值 : 


std::tr1::shared_ptr<Person> Person::create(const std::string& name, 
const Date& birthday, 
const Address& addr) 


return std::tri::shared_ptr<Person>(new RealPerson(name, birthday, addr) ); 


} 


Person::create 的 一 个 更 现实 的 实现 会 创建 不 同 派生 类 型 的 对 象 ， 依 赖 于 诸如 ， 其 他 函数 的 参 
数值 ， 从 文件 或 数据 库 读 出 的 数据 ， 环 境 变量 等 等 。 


RealPerson 示范 了 两 个 最 通用 的 实现 一 个 Interface 类 机 制 之 一 : M Interface 类 (Person) 
继承 它 的 接口 规格 ， 然 后 实现 接口 中 的 范 数 。 实 现 一 个 Interface 类 的 第 二 个 方法 包含 多 继承 
(multiple inheritance) ， 在 Item 40 中 探讨 这 个 话题 。 


Handle 类 和 Interface 类 从 实现 中 分 离 出 接口 ， 因 此 减少 了 文件 之 间 的 编译 依赖 。 如 果 你 是 一 
个 喜好 挖苦 的 人 ， 我 知道 你 正在 找 小 号 字体 写成 的 限制 。 “所 有 这 些 把 戏 会 骗 走 我 什么 呢 ? "你 
小 声 咬 咕 着 。 答 案 是 计算 机 科学 中 非常 平常 的 : 它 会 消耗 一 些 运行 时 的 速度 ， 再 加 上 每 个 对 
象 的 一 些 额外 的 内 存 。 


在 Handle 类 的 情况 下 ， 成 员 本 数 必须 通过 实现 的 指针 得 到 对 象 的 数据 。 这 就 在 每 次 访问 中 增 
加 了 一 个 间接 层 。 而 且 你 必须 在 存储 每 一 个 对 象 所 需 的 内 存量 中 增加 这 一 实现 的 指针 的 大 
小 。 最 后 ， 这 一 实现 的 指针 必须 被 初始 化 (在 Handle 类 的 构造 画 数 中 ) 为 指向 一 个 动态 分 配 
的 实现 的 对 象 ， 所 以 你 要 承受 动态 内 存 分 配 ( 以 及 随后 的 释放 ) 所 固有 的 成 本 和 遭遇 


bad alloc (out-of-memory) 异常 的 可 能 性 。 


对 于 Interface 类 ， 每 一 个 图 数 调 用 都 是 虚拟 的 ， 所 以 你 每 调用 一 次 函数 就 要 支付 一 个 间接 跳 
转 的 成 本 (参见 ltem 7) 。 还 有 ， 从 Interface 派生 的 对 象 必须 包含 一 个 virtual table 指针 
(还 是 参见 Item 7) 。 这 个 指针 可 能 增加 存储 一 个 对 象 所 需 的 内 存 的 量 ， 依 赖 于 这 个 
Interface 类 是 否 是 这 个 对 象 的 虚 函 数 的 唯一 来 源 。 


最 后 ， 无 论 Handle 类 还 是 Interface 类 都 不 能 在 inline KAHJA EAEE., Item 30 解释 了 
为 什么 函数 本 体 一 般 必须 在 头 文 件 中 才能 做 到 inline， 但 是 Handle 类 和 Interface 类 一 般 都 设 
计 成 隐藏 类 似 函 数 本 体 这 样 的 实现 细节 。 

然而 ， 因 为 它们 所 涉及 到 的 成 本 而 简单 地 放弃 Handle 类 和 Interface 类 会 成 为 一 个 严重 的 错 
误 。 虚 拟 图 数 也 是 一 样 ， 但 你 还 是 不 能 放弃 它们 ， 你 能 吗 ? (如 果 能 ， 你 看 错 书 了 。) 作为 
替代 ， 考 虑 以 一 种 改进 的 方式 使 用 这 些 技术 。 在 开发 过 程 中 ， 使 用 Handle 类 和 Interface 类 
来 最 小 化 实现 发 生变 化 时 对 客户 的 影响 。 当 能 看 出 在 速度 和 /或 大 小 上 的 不 同 足以 证 明 增 加 类 
之 间 的 耦合 是 值得 的 时 候 ， 可 以 用 具体 类 取代 Handle 类 和 Interface 类 供 产 品 使 用 。 


Things to Remember 


。 最 小 化 编译 依赖 后 面 的 一 般 想 法 是 用 对 声明 的 依赖 取代 对 定义 的 依赖 。 基 于 此 想法 的 两 
个 方法 是 Handle 类 和 Interface 类 。 


。 库 头 文件 应 该 以 完整 并 且 只 有 声明 的 形式 存在 。 无 论 是 否 包含 模板 都 适用 于 这 一 点 。 


Item 32: 确保 public inheritance 模拟 "is-a" 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


在 Some Must Watch While Some Must Sleep (W. H. Freeman and Company, 1974) 这 本 书 
A, William Dement 讲述 了 一 个 他 试图 让 他 的 学 生 的 记 住 他 的 课程 中 最 重要 的 未 西 的 故事 。 
书 中 声称 ， 他 告诉 他 的 班级 ， 一 般 的 英国 中 小 学 生 对 于 1066 年 发 生 的 Hastings 战争 的 历史 
并 没有 什么 了 解 。 他 着 重 强调 ， 如 果 一 个 孩子 记 住 了 一 点 儿 什 么 的 ， 他 或 者 她 也 就 是 记 住 了 
1066 这 个 年 代 。 对 于 上 他 的 课程 的 学 生 ，Dement 兆 兆 不 绝地 讲 ， 其 中 只 有 很 少 的 重要 信 
息 ， 包 括 安眠 药 却 引起 了 失眠 这 样 充满 趣味 的 事情 。 他 希望 他 的 学 生 即 使 忘记 课程 中 讨论 的 
其 它 每 一 件 事 ， 也 能 记 住 这 些 很 少 的 重大 事件 ， 而 且 他 在 整个 学 期 再 三 地 回顾 这 些 基础 的 内 
Bo 


在 课程 结束 的 时 候 ， 期 末 考 试 的 最 后 一 道 题 是 :“ 写 下 从 这 个 课程 中 得 到 的 ， 你 一 生 都 将 确切 
地 记 住 的 一 件 事 。" 当 Dement 给 这 次 考试 打分 的 时 候 ， 他 几乎 时 了 过 去 。 几 乎 每 一 个 人 都 写 
了 "1066"。 


因此 ， 我 一 再 煞费苦心 地 向 你 宣扬 ， 使 用 C++ 5 #74 object-oriented programming 时 唯一 
最 重要 规则 就 是 : public inheritance (公开 继承 ) 意味 着 "is-a"。 要 让 这 个 规则 刻骨 铭 心 。 


如 果 你 写 了 一 个 class D ("Derived") M class B ("Base") 公开 继承 ， 你 就 是 在 告诉 C++ 编译 

器 (以 及 你 的 代码 的 读者 ) 每 一 个 类 型 为 D 的 对 象 也 是 一 个 类 型 为 B 的 对 象 ， 但 是 反之 则 不 
然 。 你 就 是 在 说 B 描绘 了 一 个 比 D 更 一 般 的 概念 ，D 描述 了 一 个 比 B 更 特殊 的 概念 。 你 就 是 
在 声称 一 个 类 型 为 B 的 对 象 可 以 使 用 的 任何 地 方 ， 一 个 类 型 为 D 的 对 象 一 样 可 以 使 用 ， 因 为 
每 一 个 类 型 为 D 的 对 象 也 就 是 一 个 类 型 为 B 的 对 象 。 另 一 方面 ， 如 果 你 需要 一 个 类 型 为 D 的 
对 象 ， 一 个 类 型 为 B 的 对 象 则 不 行 : 每 一 个 D 都 是 一 个 B， 但 是 反之 则 不 然 。 


C++ 坚持 对 public inheritance 的 这 一 解释 。 考 虑 这 个 例子 : 


class Person {...}; 


class Student: public Person {...}; 


我 们 从 日 常 的 经 验 知道 每 一 个 学 生 都 是 一 个 人 ， 但 并 不 是 每 一 个 人 都 是 一 个 学 生 。 这 就 是 由 
这 个 继承 体系 严格 确定 的 意义 。 我 们 期 望 每 一 件 对 于 人 来 说 成 立 的 事情 一 一 例如 ， 他 或 她 有 
一 个 出 生日 对 于 一 个 学 生来 说 也 成 立 。 我 们 不 期 望 每 一 件 对 于 学 生来 说 成 立 的 事情 
例如 ， 他 或 她 在 一 所 特定 的 学 校注 册 一 一 对 于 普通 人 来 说 也 成 立 。 一 个 人 的 概念 比 一 个 学 生 
的 概念 更 普通 ， 一 个 学 生 一 个 专门 类 型 的 人 。 











在 C++ 领域 中 ， 任 何 期 望 引 数 类 型 为 Person (3 pointer-to-Person 或 reference-to- 
Person) 的 函数 都 可 以 接受 一 个 Student object (或 pointer-to-Student 或 reference-to- 
Student) 


void eat(const Person& p); // anyone can eat 

void study(const Student& s); // only students study 
Person p; // p is a Person 
Student s; // s is a Student 
eat(p); // fine, p is a Person 
eat(s); // fine, s is a Student, 


// and a Student is-a Person 
study(s); // fine 


study(p); // error! p isn't a Student 


这 一 点 只 对 public inheritance F ARIZ, RA Student 以 public 方式 从 Person WR, C++ + 
有 我 所 描述 的 行为 。private inheritance 意味 着 完全 不 同 的 其 它 事情 (参见 Item 39) ， 而 
protected inheritance 究竟 意味 什么 使 我 困惑 至 今 。 


public inheritance 和 is-a 等 价 听 起 来 简单 ， 但 有 时 你 的 直觉 会 误导 你 。 例 如 ， 企 掀 是 一 种 乌 
没有 问题 ， 而 乌 能 飞 也 没有 问题 。 如 果 我 们 天 真 地 试图 用 C++ 来 表达 ， 我 们 就 会 得 到 : 


class Bird { 


public: 
virtual void fly(); // birds can fly 
}; 
class Penguin:public Bird { // penguins are birds 
}; 


突然 间 我 们 遇 到 了 麻烦 ， 因 为 这 个 继承 体系 表示 企 忽 能 飞 ， 我 们 知道 这 不 是 真 的 。 发 生 了 什 
么 呢 ? 


在 这 种 情况 下 ， 我 们 成 了 不 严 尊 的 语言 一 一 英语 的 特 牲 品 。 当 我 们 说 乌 能 飞 的 时 候 ， 我 们 的 
意思 并 非 是 说 所 有 种 类 的 乌 都 能 飞 ， 我 们 不 过 是 说 ， 大 体 上 ， 乌 有 飞 的 能 力 。 如 果 我 们 说 得 
更 准确 些 ， 我 们 应 该 承认 有 几 种 不 能 飞 的 鸟 ， 并 提出 如 下 继承 体系 ， 它 对 事实 的 模拟 要 好 得 
多 : 


class Bird { 


}; 
class FlyingBird: public Bird { 


public: 
virtual void fly(); 


T 


class Penguin: public Bird { 


// no fly function is declared 


// no fly function is declared 


这 个 继承 体系 比 最 初 的 设计 更 忠实 于 我 们 真正 知道 的 东西 。 


至 此 我 们 还 是 没有 完全 做 好 关于 这 些 乌 的 事情 ， 因 为 对 于 某 些 软件 系统 来 说 ， 可 能 并 不 需要 
区 分 能 飞 的 和 不 能 飞 的 乌 。 如 果 你 的 应 用 程序 对 于 乌 吹 和 乌 收 做 了 很 多 处 理 ， 而 不 打算 对 飞 
行 做 什么 处 理 的 话 ， 最 初 的 two-class 的 继承 体系 可 能 完全 适用 。 它 是 对 “没有 一 个 适用 于 所 
有 软件 的 完美 设计 "这样 的 事实 的 一 个 简单 反映 。 最 好 的 设计 依赖 于 系统 儿 竟 期 望 做 什么 ， 无 
论 现 在 还 是 未 来 。 如 果 你 的 程序 对 飞行 一 无 所 知 ， 而 且 也 不 期 望 以 后 能 知道 些 什么 ， 那 么 不 
分 辨 能 飞 与 不 能 飞 的 乌 可 能 就 是 一 个 非常 完美 的 设计 决策 。 事 实 上 ， 它 可 能 比 区 分 它们 的 设 
计 更 为 可 取 ， 因 为 你 试图 模拟 的 世界 中 就 没有 这 样 一 种 区 分 。。 

对 于 如 何 处 理 我 所 说 的 "所 有 的 乌 能 飞 ， 企 掀 是 鸟 ， 企 笋 不 能 飞 ， 啊 .…... 哦 .…...” 的 问题 ， 还 有 
另 一 种 思想 观念 。 那 就 是 为 企 殷 重 定义 fly 豆 数 ， 以 便 让 它 产生 一 个 运行 时 错误 。 


void error(const std::string& msg); // defined elsewhere 
class Penguin: public Bird { 


public: 
virtual void fly() { error("Attempt to make a penguin fly!");} 


认可 “这 里 所 说 的 一 些 事情 与 你 所 想 的 可 能 不 同 " 是 很 重要 的 。 这 不 是 说 “ 企 笋 不 能 飞 ”。 而 是 
说 “企鹅 能 飞 ， 但 对 它 试 图 真 的 这 样 做 就 是 一 个 错误 ”。 


你 能 说 出 其 中 的 区 别 吗 ? 从 错误 被 发 觉 时 间 方 面 看 。“ 企 殷 不 能 飞 ” 的 禁 命 可 以 由 编译 器 强 合 执 
行 ， 但 是 对 “让 企 掀 真 的 去 飞 是 一 个 错误 "的 规约 的 违反 ， 只 有 在 运行 时 才能 被 发 觉 。 


为 了 表达 “企鹅 不 能 飞 ” 这 个 限制 ， 你 要 确保 不 要 为 Penguin 对 象 定义 这 样 的 图 数 : 


class Bird { 

// no fly function is declared 
J; 
class Penguin: public Bird { 


// no fly function is declared 


如 果 你 现在 试图 让 企 艇 飞 ， 编 译 器 将 因为 你 的 违例 而 乱 罚 你 : 


Penguin p; 


p.fly(); // error! 


这 与 你 采用 产生 运行 时 错误 的 方法 ， 得 到 完全 不 同 的 行为 。 使 用 那个 方法 ， 关 于 对 p.fly 的 调 
用 ， 编 译 器 一 言 不 发 。ltem 18 解释 了 好 的 接口 可 以 在 编译 时 防止 非法 代码 ， 所 以 你 应 该 用 通 
过 编译 器 阻止 企 忽 飞翔 企图 的 设计 代替 只 在 运行 时 检测 的 设计 

也 许 你 会 承认 你 的 乌 类 学 知识 可 能 不 足 ， 但 是 你 对 自己 对 基本 几何 学 的 掌握 很 自信 ， 是 吗 ? 
我 的 意思 是 说 ， 和 矩形 和 正方 形 能 有 多 么 复杂 ? 


好 吧 ， 回 答 这 个 简单 的 问题 : 应 该 让 class Square 从 class Rectangle 公开 继承 吗 ? 





“On! UR, “当然 应 该 ! 每 一 个 人 都 知道 一 个 正方 形 就 是 一 个 矩形， 但 是 反 过 来 就 不 一 定 
Jo "这 完全 正确 ， 至 少 在 学 校 里 是 。 但 是 我 不 认为 我 们 现在 还 在 学 校 里 。 


考虑 如 下 代码 : 


class Rectangle { 

public: 
virtual void setHeight(int newHeight); 
virtual void setWidth(int newWidth); 


virtual int height() const; // return current values 
virtual int width() const; 


}; 

void makeBigger(Rectangle& r) // function to increase r's area 
int oldHeight = r.height(); 
r.setWidth(r.width() + 10); // add 10 to r's width 
assert(r.height() == oldHeight); // assert that r's 

} // height is unchanged 


= 


很 清楚 ， 断 言 应 该 永远 不 会 失败 。makeBigger 仅仅 改变 了 Tf 的 宽度 ， 它 的 高 度 始终 没有 变 


现在 ， 考 虑 以 下 代码 ， 使 用 public inheritance 使 得 squares 可 以 像 rectangles 一 样 进行 处 
理 : 


class Square: public Rectangle {...}; 


Square s; 

assert(s.width() == s.height()); // this must be true for all squares 

makeBigger(s); // by inheritance, s is-a Rectangle, 
// SO we can increase its area 

assert(s.width() == s.height()); // this must still be true 


// for all squares 
和 刚才 那个 一 样 明显 ， 第 二 个 断言 也 应 该 永远 不 会 失败 。 根 据 定义 ， 正 方形 的 宽度 和 高 度 是 
相等 的 。 
但 是 ， 现 在 有 一 个 问题 ， 我 们 怎样 才能 协调 以 下 断言 ? 

。 调用 makeBigger 之 前 ，s 的 高 度 和 它 的 宽度 相等 ; 

。 在 makeBigger 内 ，s 的 宽度 发 生变 化 ， 但 是 它 的 高 度 没有 变化 ; 


e 从 makeBigger 返回 之 后 ，s 的 高 度 还 要 和 它 的 宽度 相等 。 (注意 s 是 通过 by reference 
方式 传人 makeBigger 的 ， 所 以 makeBigger 能 改变 s 自身 ， 而 不 是 s 的 拷贝 。) 


嘟 嘟 ? 





欢迎 来 到 public inheritance 的 奇妙 世界 ， 你 在 其 它 学 习 领 域 
本 能 ， 可 能 不 再 像 你 所 期 望 的 那样 帮助 你 。 在 这 种 情况 下 ， 基 本 的 难点 在 于 一 
( 它 的 宽度 可 以 独立 于 他 的 高 度 而 自行 变化 ) 的 事情 不 适用 于 正方 形 〈 它 的 宽度 和 高 度 必 须 
相等 ) 。 但 是 public inheritance 断言 ， 适 用 于 base class objects 〈 基 类 对 象 ) 的 每 一 件 事 
— 每 一 件 事 | 一 一 也 适用 于 derived class objects (派生 类 对 象 ) 。 在 矩形 和 正方 形 的 情况 
FT (还 有 Item 38 中 一 个 包含 sets 和 lists 的 例子 ) ， 这 个 断言 失效 ， 所 以 用 public 
inheritance 模拟 它们 的 关系 是 完全 错误 的 。 编 译 器 允许 你 这 样 做 ， 但 是 就 像 我 们 已 经 看 到 
的 ， 它 不 能 保证 代码 的 行为 正确 。 每 一 个 程序 员 都 必须 认识 到 ， 人 和 仅仅 通过 编译 的 代码 ， 并 不 
意味 着 它 可 以 工作 。 


不 必 忧 虑 你 在 过 去 这 些 年 发 展 起 来 的 软件 直觉 在 你 走 近 object-oriented design 时 和 失效。 那些 
知识 依然 是 有 价值 的 ， 但 是 现在 你 应 该 在 你 的 设计 候选 武器 库 中 加 入 inheritance， 你 还 必须 
在 你 的 直觉 中 加 入 新 的 洞察 力 来 指导 你 正确 使 用 inheritance。 当 某 个 人 向 你 展示 一 个 几 页 长 
的 函数 时 ， 你 可 能 会 及 时 地 从 Penguin 继承 自 Bird 或 Square 继承 自 Rectangle 得 到 有 趣 的 
感觉 。 它 可 能 是 接近 事实 的 正确 方法 ， 只 是 不 太 像 而 已 。 


is-a 关系 并 不 是 能 存在 于 两 个 classes 之 间 的 唯一 关系 。 另 外 两 个 常见 的 inter-class 关系 是 
"has-a" 和 "is-implemented-in-terms-of'"。 这 些 关系 将 在 Item 38 和 39 中 考虑 。 因 为 用 这 些 其 
它 重 要 关系 中 的 一 个 来 不 正确 地 模拟 is-a 而 造成 的 C++ 设计 错误 并 不 罕见 ， 所 以 你 应 该 确保 
你 理解 了 这 些 关系 之 间 的 不 同 ， 并 知道 在 C++ 中 如 何 才 能 用 它们 做 最 好 的 模拟 。 


Things to Remember 


e public inheritance 意味 着 "is-a"。 适 用 于 base classes 的 每 一 件 事 也 适用 于 derived 
classes， 因 为 每 一 个 derived class object 都 是 一 个 base class object. 


Item 33: 避免 覆盖 (hiding) “通过 继承 得 到 的 名 


-F 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


莎士比亚 有 一 个 关于 名 字 的 说 法 。"What's in a name?" 他 问 道 ，"A rose by any other name 

would smell as sweet.”( 语 出 《罗密欧 与 朱丽叶 》 第 二 幕 第 二 场 ， 朱 生 豪 先生 译 为 : “姓名 本 
来 是 没有 意义 的 ; 我 们 叫做 玫瑰 的 这 一 种 花 ， 要 是 换 了 个 名 字 ， 他 的 香味 还 是 同样 的 芬 

Bo "梁实秋 先生 译 为 :“ 姓 算 什么 ?我们 所 谓 有 玫瑰 ， 换 个 名 字 ， 还 是 一 样 的 香 。 "一 一 译 者 

注 ) o Wte Eat "he that filches from me my good name ... makes me poor indeed." ( 语 出 
《 奥 塞 罗 》 第 三 幕 第 三 场 ， 朱 生 豪 先生 译 为 : “可 是 谁 偷 去 了 我 的 名 誉 ， 那 么 他 虽然 并 不 因此 
而 富足 ， 我 却 因为 失去 它 而 成 为 赤 贫 了 。 ”梁实秋 先生 译 为 :“ 但 是 他 若 夺 去 我 的 名 誉 ， 于 他 不 
见 有 利 ， 对 我 却 是 一 件 损失 哩 。 AE) 。 好 吧 ， 在 C++ 中， 我们 该 用 哪 种 态度 对 待 通 
过 继承 得 到 的 名 字 呢 ? 








事情 的 实质 与 继承 没什么 关系 。 它 与 作用 域 有 关 。 我 们 都 知道 它 在 代码 中 是 这 样 的 ， 


int x; // global variable 
void someFunc() 
double x; // local variable 


std::cin >> x; // read a new value for local x 


} 


ZA x 的 语句 指 涉 local 变量 x， 而 不 是 global 变量 x， 因为 内 层 作 用 域 的 名 字 覆 盖 (“ 遮 
he’) 外 层 作 用 域 的 名 字 。 我 们 可 以 像 这 样 形象 地 表示 作用 域 的 状况 : 


Global scope 


| 
E someFunc’s scope 
| 
| 


当 编译 器 在 someFunc 的 作用 域 中 遇 到 名 字 x 时 ， 他 们 巡视 local 作用 域 看 看 是 否 有 什么 东西 
叫 这 个 名 字 。 因 为 那里 有 ， 它 们 就 不 再 检查 其 它 作用 域 。 在 此 例 中 ，someFunc 的 x 类 型 为 
double, m global x 类 型 为 int， 但 这 不 要 紧 。C++ 的 name-hiding 规则 仅仅 是 覆盖 那个 名 
字 。 而 相对 应 的 名 字 的 类 型 是 否 相 同 是 无 关 紧 要 的 。 在 此 例 中 ， 一 个 名 为 x double 覆盖 了 
一 个 名 为 x 的 int, 





加 入 inheritance 以 后 。 我 们 知道 当 我 们 在 一 个 derived class member function 内 指 涉 位 于 
base class 内 的 一 件 东 西 ( 例 如， 一 个 member function， 一 个 typedef， 或 者 一 个 data 
member) 时 ， 编 译 器 能 够 找到 我 们 指 涉 的 东西 是 因为 derived classes 继承 到 声明 于 base 
classes 中 的 东西 。 实 际 中 的 运作 方法 是 将 derived class 的 作用 域 嵌 套 在 base class 作用 域 
之 中 。 例 如 : 


class Base { 
private: 
int x; 


public: 
virtual void mfi() = 0; 
virtual void mf2(); 
void mf3(); 


ser 


class Derived: public Base { 
public: 

virtual void mf1(); 

void mf4(); 


T 


Base's scope 


x (data member) 
mf1 (1 function) 
mf2 (1 function) 
mf3 (1 function) 


Derived's scope 


mf1 (1 function) 
mf4 (1 function) 





API AASHEA public 名 字 也 有 private 4, BEA data members 也 有 member 
functions, member functions BE4 pure virtual 的 ， 也 有 simple (impure) virtual 的 ， 还 有 
non-virtual 的 。 那 是 为 了 强调 我 们 谈论 的 事情 是 关于 名 字 的 。 例 子 中 还 可 以 包括 其 它 类 型 的 名 
字 ， 例 如 ，enums，nested classes， 和 typedefs。 在 这 里 的 讨论 中 唯一 重要 的 事情 是 “它们 
是 名 字 ”。 和 与 它们 是 什么 东西 的 名 字 毫 不 相关 。 这 个 示例 中 使 用 了 single inheritance， 但 是 一 
旦 你 理解 了 在 single inheritance 下 会 发 生 什 么 ，C++ 在 multiple inheritance 下 的 行为 就 很 容 
易 预 见 了 。 


假设 mf4 在 derived class 中 被 实现 ， 其 中 一 部 分 ， 如 下 : 


void Derived: :mf4() 


mf2(); 


当 编 译 器 看 到 这 里 对 名 字 mf2 的 使 用 ， 它 就 必须 断定 它 指 涉 什 么 。 它 通过 搜索 名 为 mf2 的 某 
物 的 定义 的 作用 域 来 做 这 件 事 。 首 先 它 在 loca 作用 域 中 搜索 (也 就 是 mf4 的 作用 域 ) ， 但 是 
它 没有 找到 被 称 为 mf2 的 任何 东西 的 声明 。 然 后 它 搜索 它 的 包含 作用 域 ， 也 就 是 class 
Derived 的 作用 域 。 它 依然 没有 找到 叫做 mf2 的 任何 东西 ， 所 以 它 上 移 到 它 的 上 一 层 包 含 作 
用 域 ， 也 就 是 base class 的 作用 域 。 在 那里 它 找到 了 名 为 mf2 的 东西 ， 所 以 搜索 停止 。 如 果 
在 Base 中 没有 mf2， 搜 索 还 会 继续 ， 首 先是 包含 Base 的 namespace(s) (如 果 有 的 话 ) ， 
最 后 是 global 作用 域 。 


我 刚刚 描述 的 过 程 虽然 是 正确 的 ， 但 它 还 不 是 一 个 关于 C++ 中 名 字 如 何 被 找到 的 完整 的 描 
述 。 无 论 如 何 ， 我 们 的 目的 不 是 为 了 充分 了 解 关 于 写 一 个 编译 器 时 的 名 字 搜 索 问 题 。 而 是 为 
了 充分 了 解 如何 避 免 合 人 吃惊 的 意外 ， 而 对 于 这 个 任务 ， 我 们 已 经 有 了 大 量 的 信息 。 


再 次 考虑 前 面 的 示例 ， 而 且 这 一 次 我 们 overload mf1 和 mf3， 并 且 为 Derived 增加 一 个 mf3 
的 版 本 。 (就 像 Item 36 解释 的 ，Derived 对 mf3 一 一 一 个 通过 继承 得 到 的 non-virtual 
function 一 一 的 重 载 ， 使 得 这 个 设计 立即 变 得 可 疑 ， 但 是 出 于 对 inheritance 之 下 名 字 可 见 性 
问题 的 关心 ， 我 们 就 装 作 没 看 见 。) 


class Base { 
private: 
int x; 


public: 
virtual void mfi() = 0; 
virtual void mfi(int); 


virtual void mf2(); 


void mf3(); 
void mf3(double); 


}; 


class Derived: public Base { 
public: 

virtual void mf1(); 

void mf3(); 

void mf4(); 


}; 





Base's scope 







x (data member) 
mf1 (2 functions) 
mf2 (1 function) 

mf3 (2 functions) 


Derived’s scope 
mf (1 function) 
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mf4 (1 function) 





以 上 代码 导致 的 行为 会 使 每 一 个 第 一 次 遇 到 它 的 C++ 程序 员 吃 惊 。 基 于 作用 域 的 名 字 覆 盖 规 
则 (scope-based name hiding rule) 不 会 有 什么 变化 ， 所 以 base class 中 的 所 有 名 为 mf1 和 
mf3 的 函数 被 derived class 中 的 名 为 mf1 和 mf3 的 函数 覆盖 。 从 名 字 搜 索 的 观点 看 ， 
Base::mf1 和 Base::mf3 不 再 被 Derived 继承 ! 


Derived d; 


int x; 

d.mfi(); // fine, calls Derived: :mf1 

d.mf1(x); // error! Derived: :mf1 hides Base::mf1i 
d.mf2(); // fine, calls Base: :mf2 

d.mf3(); // fine, calls Derived: :mf3 

d.mf3(x); // error! Derived: :mf3 hides Base::mf3 


就 像 你 看 到 的 ， 即 使 base 和 derived classes 中 的 函数 具有 不 同 的 参数 类 型 ， 它 也 同样 适 

H, METERA virtual 还 是 non-virtual， 它 也 同样 适用 。 与 “在 本 Item 的 开始 人 处， 函数 
someFunc 中 的 double x Æ% 7 global 作用 域 中 的 int x” 的 道理 相同 ， 这 里 Derived 中 的 函数 
mf3 履 盖 了 具有 不 同类 型 的 名 为 mf3 的 一 个 Base HR. 


这 一 行为 背后 的 根本 原因 是 为 了 防止 “ 当 你 在 一 个 library 或 者 application framework 中 创建 一 
个 新 的 derived class 时 ， 偶 然 地 发 生 从 遥远 的 base classes 继承 overloads 的 情况 ”。 不 幸 
的 是 ， 一 般 情况 下 你 是 需要 继承 这 些 overloads 的 。 实 际 上 ， 如 果 你 使 用 了 public 
inheritance 而 又 没有 继承 这 些 overloads， 你 就 违反 了 Item 32 讲解 的 “base 和 derived 
classes 之 间 是 is-a 关系 ”这 一 public inheritance 的 基本 原则 。 在 这 种 情况 下 ， 你 几乎 总 是 
绕 过 C++ 对 "通过 继承 得 到 的 名 字 ” 的 缺 省 的 履 盖 机 制 。 


你 可 以 用 using declarations 做 到 这 一 点 : 


class Base { 
private: 
int x; 


public: 
virtual void mf1() = 0; 
virtual void mf1i(int); 


virtual void mf2(); 


void mf3(); 
void mf3(double); 


J; 

class Derived: public Base { 

public: 
using Base: :mf1; // make all things in Base named mf1 and mf3 
using Base: :mf3; // “isible (and public) in Derived's scope 


virtual void mf1(); 
void mf3(); 
void mf4(); 


a 


Base’s scope 


x (data member) 
mf1 (2 functions) 
mf2 (1 function) 
mf3 (2 functions) 


Derived’s scope 


mf1 (2 functions) 
mf3 (2 functions) 
mf4 (1 function) 





现在 inheritance 就 可 以 起 到 预期 的 作用 : 


Derived d; 


int x; 

d.mf1(); // still fine, still calls Derived: :mf1 
d.mf1(x); // now okay, calls Base: :mf1 

d.mf2(); // still fine, still calls Base: :mf2 
d.mf3(); // fine, calls Derived: :mf3 

d.mf3(x); // now okay, calls Base: :mf3 


REBRAURMM—T FAS AWA base class 继承 ， 而 且 你 只 想 重 定义 或 替换 它们 中 的 
一 部 分 ， 你 需要 为 每 一 个 你 不 想 覆 盖 的 名 字 使 用 using declaration。 如 果 你 不 这 样 做 ， 一 些 你 
希望 继承 下 来 的 名 字 会 被 覆盖 。 


可 以 想象 在 某 些 时 候 你 不 希望 从 你 的 base classes 继承 所 有 的 函数 。 在 public inheritance 
中 ， 这 是 绝 不 会 发 生 的 ， 这 还 是 因为 ， 它 违反 了 public inheritance 在 base 和 derived 
classes 之 间 的 is-a 关系 。 (这 就 是 为 什么 上 面 的 using declarations 在 derived class 的 
public 部 分 : 在 base class 中 是 public 的 名 字 在 公有 继承 的 derived class 中 也 应 该 是 
public, ) 然而 ， 在 private inheritance (参见 Item 39) 中 ， 它 还 是 有 意义 的 。 例 如 ， 假 设 
Derived M Base 私有 继承 ， 而 且 Derived 只 想 继 承 没 有 参数 的 那个 mf1 的 版 本 。 在 这 里 ， 
using declaration 没有 这 个 本 事 ， 因 为 一 个 using declaration 会 使 得 所 有 有 具有 给 定名 字 的 函 
数 在 derived class 中 可 见 。 不 ， 这 里 是 使 用 了 一 种 不 同 的 技术 的 情形 ， 即 ， 一 个 简单 的 
forwarding function (转调 函数 ) 


class Base { 

public: 
virtual void mf1() = 0; 
virtual void mfi(int); 


// as before 


J; 

class Derived: private Base { 

public: 
virtual void mf1() // forwarding function; implicitly 
{ Base: :mf1(); } // inline (see Item 30) 

J; 


Derived d; 


int x; 
d.mf1(); // fine, calls Derived: :mf1 
d.mf1(x); // error! Base::mf1() is hidden 


forwarding function (H ARŠO 的 另 一 个 功效 是 用 于 老式 的 编译 器 ， 它 们 (不 正确 地 ) BX 
持 用 using declarations 将 “通过 继承 得 到 的 名 字 ” 引 入 到 derived class 的 作用 域 。 


这 就 是 关于 inheritance 和 name hiding 的 全 部 故事 ， 但 是 当 inheritance 4 templates 结合 起 
K, “通过 继承 得 到 的 名 字 被 隐藏 "的 问题 会 以 一 种 全 然 不 同 的 形式 呈现 出 来 。 关 于 全 部 angle- 
bracket-demarcated ( 边 边 角 角 ) 的 细节 ， 参 见 Item 43。 


Things to Remember 


e derived classes FAJA FÆ% base classes 中 的 名 字 ， 在 public inheritance 中 ， 这 从 来 
不 是 想 要 的 。 


。 为 了 使 隐藏 的 名 字 重 新 可 见 ， 使 用 using declarations 或 者 forwarding functions (435E 
数 ) 。 


Item 34: X4 inheritance of interface (接口 继 
7K) 和 inheritance of implementation (实现 继 


7K ) 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


(public) inheritance 这 个 表面 上 简单 易 懂 的 观念 ， 一 旦 被 近 距离 审视 ， 就 会 被 证 明 是 由 两 个 相 
互 独立 的 部 分 组 成 的 : inheritance of function interfaces (函数 接口 的 继承 ) 和 inheritance of 
function implementations (E232 SLAY 4E-K) 。 这 两 种 inheritance 之 间 的 差异 正好 符合 本 书 
Introduction 中 论述 的 function declarations (函数 声明 ) 和 function definitions (ARE 3) 
之 间 的 差异 。 


作为 一 个 class 的 设计 者 ， 有 的 时 候 你 想 要 derived classes 只 继承 一 个 member function 的 
interface (declaration)。 有 的 时 候 你 想 要 derived classes 既 继 承 interface (接口 ) 也 继承 
implementation (实现 ) ， 但 你 要 允许 它们 蔡 换 他们 继承 到 的 implementation。 还 有 的 时 候 你 
想 要 derived classes 继承 一 个 画 数 的 interface (接口 ) 和 implementation (实现 ) ， 而 不 允 
许 它们 替换 任何 东西 。 


为 了 更 好 地 感觉 这 些 选 择 之 间 的 不 同 之 处 ， 考 虑 一 个 在 图 形 点 用 程序 中 表示 几何 图 形 的 class 
hierarchy (类 继承 体系 ) 
class Shape { 
public: 
virtual void draw() const = 0; 


virtual void error(const std::string& msg); 


int objectID() const; 


}; 
class Rectangle: public Shape { ... }; 
class Ellipse: public Shape { ... }; 


Shape =—~ abstract class (抽象 类 ) ， 它 的 pure virtual function 〈 纯 虚拟 函数 ) 表明 了 这 
一 点 。 作 为 结果 ， 客 户 不 能 创建 Shape class 的 实例 ， 只 能 创建 从 它 继 承 的 classes 的 实例 。 
但 是 ，Shape 对 所 有 从 它 (公有) 继承 的 类 施加 了 非常 强大 的 影响 ， 因 为 


BX it EX interfaces are always inherited。 就 像 Item 32 解释 的 ，public inheritance 意味 着 
is-a， 所 以 对 一 个 base class 来 说 成 立 的 任何 东西 ， 对 于 它 的 derived classes 也 必须 成 立 。 
因此 ， 如 果 一 个 函数 适用 于 一 个 class， 它 也 一 定 适用 于 它 的 derived classes. 


Shape class 中 声明 了 三 个 函数 。 第 一 个 ，draw,， ee 出 当前 对 象 。 第 
二 个 ，error， 如 果 member functions 需要 报告 一 个 错误 ， 就 调用 它 。 第 三 个 ，objectID， 返 
回 当前 对 象 的 唯一 整 型 标识 符 。 Z draw 是 一 个 pure virtual 
function (EWE) ; error 是 一 个 simple (impure?) virtual function (简单 虚拟 函数 ) ; 
而 objectID 是 一 个 non-virtual function 〈 非 虚拟 函数 ) 。 这 些 不 同 的 声明 暗示 了 什么 呢 ? 


考虑 第 一 个 pure virtual function (4452 EN) draw : 


class Shape { 
public: 
virtual void draw() const = 0; 


er 


pure virtual functions (44.82) 的 两 个 最 显著 的 特性 是 它们 必须 被 任何 继承 它们 的 具体 
类 重新 声明 ， 和 抽象 类 中 一 般 没有 它们 的 定义 。 把 这 两 个 特性 加 在 一 起 ， 你 应 该 认识 到 


声明 一 个 pure virtual function 〈 纯 虚拟 函数 ) 的 目的 是 使 derived classes 继承 一 个 函数 
interface 


这 就 使 Shape::draw function 具有 了 完整 的 意义 ， 因 为 aed Shape 对 象 必须 
出 来 是 合情合理 的 ， 但 是 Shape class ABA HX THREE ears ai 
现 。 例 如 ， 画 一 个 椭圆 的 算法 和 画 一 个 矩形 的 算法 是 非常 不 同 的 ， aoe :draw 的 声明 告诉 具 
体 derived classes 的 设计 者 :“ 你 必须 提供 一 个 draw function， 但 是 我 对 于 你 如 何 实现 它 不 
发 表意 见 。” 


顺便 提 一 句 ， 为 一 个 pure virtual function (EMEK 提供 一 个 定义 是 有 可 能 的 。 也 就 是 
说 ， 你 可 以 为 Shape::draw 提供 一 个 实现 ， 而 C++ 也 不 会 抱怨 什么 ， 但 是 调用 它 的 唯一 方法 
是 用 class name 限定 修饰 这 个 调用 : 


Shape *ps = new Shape; // error! Shape is abstract 
Shape *psi = new Rectangle; // fine 

psi->draw(); // calls Rectangle: :draw 
Shape *ps2 = new Ellipse; // fine 

ps2->draw(); // calls Ellipse: :draw 
psi->Shape: :draw(); // calls Shape: :draw 
ps2->Shape: :draw(); // calls Shape: :draw 


除了 帮助 你 在 鸡尾酒 会 上 给 同行 程序 员 留 下 印象 外 ， 这 个 特性 通常 没什么 用 处 ， 然 而 ， 就 像 
下 面 你 将 看 到 的 ， Re simple (impure) virtual functions 提供 一 个 safer- 
than-usual 的 实现 ”的 机 制 。 


simple virtual functions 背后 的 故事 和 pure virtuals 有 一 点 不 同 。derived classes 照常 还 是 继 
AKAH interface， 但 是 simple virtual functions 提供 了 一 个 可 以 被 derived classes 替换 的 
实现 。 如 果 你 为 此 考虑 一 阵 儿 ， 你 就 会 认识 到 


声明 一 个 simple virtual function 的 目的 是 让 derived classes 继承 一 个 辑 数 interface as well 
as a default implementation。 


考虑 Shape::error 的 情况 : 


class Shape { 
public: 
virtual void error(const std::string& msg); 


E 


interface 要 求 每 一 个 class 必须 支持 一 个 在 遭遇 到 错误 时 被 调用 的 函数 ， 但 是 每 一 个 class 可 
以 自由 地 用 它 党 得 合适 的 任何 方法 义理 错误 。 如 果 一 个 class 不 需要 做 什么 特别 的 事情 ， 它 可 
以 仅仅 求助 于 Shape class 中 提供 的 错误 义理 的 缺 省 版 本 。 也 就 是 说 ，Shape::error 的 声明 告 
诉 derived classes 的 设计 者 :“ 你 应 该 支持 一 个 error function， 但 如 果 你 不 想 自己 写 ， 你 可 
以 求助 Shape class 中 的 缺 省 版 本 。” 


结果 是 : 允许 simple virtual functions 既 指 定 一 个 画 数 接口 又 指定 一 个 缺 省 实现 是 危险 的 。 来 
看 一 下 为 什么 ， 考 虑 一 个 XYZ 航空 公司 的 飞机 的 hierarchy (继承 体系 ) 。XYZ 只 有 两 种 飞 
机 ，ModelA 和 Model B， 它 们 都 严格 地 按照 同样 的 方法 飞行 。 于 是 ，XYZ 设计 如 下 
hierarchy (继承 体系 ) 


class Airport { ... }; // represents airports 
class Airplane { 


public: 
virtual void fly(const Airport& destination); 


J; 
void Airplane: :fly(const Airport& destination) 


default code for flying an airplane to the given destination 


} 
class ModelA: public Airplane { ... }; 
class ModelB: public Airplane { ... }; 


为 了 表述 所 有 的 飞机 必须 支持 一 个 fly BA, HHA 了“ 不同 机 型 可 能 (在 理论 上 ) 需要 不 同 的 对 
fly 的 实现 ”的 事实 ，Airplane::fly 被 声明 为 virtual。 然 而 ， 为 了 避免 在 ModelA 和 ModelB 
classes 中 些 重复 的 代码 ， 缺 省 的 飞行 行为 由 Airplane::fly 的 画 数 体 提供 ， 供 ModelA 和 
ModelB 继承 。 


这 是 一 个 经 典 的 object-oriented 设计 。 因 为 两 个 classes 共享 一 个 通用 特性 (它们 实现 fly 的 
方法 ) ， 所 以 这 个 通用 特性 就 被 转移 到 一 个 base class 之 中 ， 并 由 两 个 classes 来 继承 这 个 
特性 。 这 个 设计 使 得 通用 特性 变 得 清楚 明白 ， 避 免 了 代码 重复 ， 提 升 了 未 来 的 可 扩展 性 ， 简 
化 了 长 期 的 维护 一 因为 object-oriented 技术 ， 所 有 这 些 东 西 都 受到 很 高 的 追捧 。XYZ 航空 
公司 应 该 引 以 为 荣 。 


现在 ， 假 设 XYZ 公司 的 财富 增长 了 ， 决 定 引 进 一 种 新 机 型 ，Model Co Model C 在 某 些 方 面 
与 ModelA 和 Model B 不 同 。 特 别 是 ， 它 的 飞行 不 同 。 


XYZ 公司 的 程序 员 在 hierarchy (继承 体系 ) 中 增加 了 Model C 的 class， 但 是 由 于 他 们 匆匆 
忙 忙 地址 新 的 机 型 投入 服务 ， 他 们 忘记 了 重 定义 fly function : 


class ModelC: public Airplane { 


// no fly function is declared 


a 


于 是 ， 在 他 们 的 代码 中 ， 就 出 现 了 类 似 这 样 的 东西 : 


Airport PDX(...); // PDX is the airport near my home 


Airplane *pa = new ModelC; 
pa->fly(PDX); // calls Airplane::fly! 


这 是 一 个 灾难 : 企图 让 一 个 ModelC object 像 一 个 ModelA  ModelB 一 样 飞行 。 这 在 旅行 人 
群 中 可 不 是 一 种 鼓舞 人 心 的 行为 。 


这 里 的 问题 并 不 在 于 Airplane::fly 有 缺 省 的 行为 ， 而 是 在 于 ModelC 被 允许 不 必 明 确 说 出 它 要 
做 什么 就 可 以 继承 这 一 行为 。 幸 运 的 是 ，“ 为 derived classes (派生 类 ) 提供 缺 省 的 行为 ， 但 
是 除非 它们 提出 明确 的 要 求 ， 否 则 就 不 交 给 他 们 "是 很 容易 做 到 的 。 这 个 诀窍 就 是 切断 virtual 
function (虚拟 函数 ) 的 interface (接口 ) 和 它 的 default implementation ( 缺 省 实现 ) 之 间 的 
联系 。 以 下 用 的 就 是 这 个 方法 : 


class Airplane { 
public: 
virtual void fly(const Airport& destination) = 0; 


protected: 
void defaultFly(const Airport& destination); 


J; 
void Airplane: :defaultFly(const Airport& destination) 


default code for flying an airplane to the given destination 


} 


注意 Airplane::fly 是 被 如 何 变 成 一 个 pure virtual function (HMw) 的 。 它 为 飞行 提供 了 
interface (#20) 。 那 个 缺 省 的 实现 也 会 出 现在 Airplane class 中 ， 但 是 现在 它 是 一 个 独立 的 
KZ, defaultFly. & ModelA 和 ModelB 这 样 需要 使 用 缺 省 行为 的 Classes 只 是 需要 在 他 们 
的 fly 的 函数 体 中 做 一 下 对 defaultFly 的 inline 调用 (但 是 请 参见 Item 30 提供 的 关于 inline 
化 和 virtual functions (虚拟 函数 ) 的 交互 作用 的 信息 ) 


class ModelA: public Airplane { 

public: 
virtual void fly(const Airport& destination) 
{ defaultFly(destination); } 


}; 
class ModelB: public Airplane { 
public: 


virtual void fly(const Airport& destination) 
{ defaultFly(destination); } 


Cie 


对 于 ModelC class， 不 可 能 在 无 意 中 继 承 到 不 正确 的 fly 的 实现 ， 因 为 Airplane 中 的 pure 
virtual 〈 纯 虚拟 ) 强制 要 求 ModelC 提供 的 它 自己 的 fly 版本。 


class ModelC: public Airplane { 
public: 
virtual void fly(const Airport& destination); 


}; 
void ModelC::fly(const Airport& destination) 


code for flying a ModelC airplane to the given destination 


} 


一 方案 并 非 十 分 安全 (程序 员 还 是 能 通过 copy-and-paste 使 他 们 自己 陷入 麻烦 ) ， 但 是 它 
ea eee. 至 于 Airplane::defaultFly, tz protected ( 保 折 的 ) 是 因为 它 完 
是 Airplane 和 它 的 derived classes (派生 类 ) 的 实现 细节 。 使 用 飞机 的 客户 应 该 只 在 意 它 能 
飞 ， 而 不 必 管 飞行 是 如 何 实现 的 。 


Airplane::defaultFly 是 一 个 non-virtual function (〈 非 虚拟 函数 ) 这 一 点 也 很 重要 。 这 是 因为 
derived class (派生 类 ) 不 上 应 该 重 定 义 这 个 图 数 ， 这 是 一 个 在 ltem 36 中 专门 介绍 的 原则 。 如 
果 defaultFly Æ virtual (虚拟 的 ) ， 你 就 会 遇 到 一 个 循环 的 问题 : 如 果 某 些 derived class (ik 
生 类 ) 应 该 重 定义 defaultFly 却 忘记 了 的 时 候 会 如 何 呢 ? 


一 些 人 反对 为 interface (接口 ) 和 default implementation ( 缺 省 实现 ) 分 别提 供 画 数 ， 就 像 
上 面 的 fly 和 defaultFly 那样 。 首 先 ， 他 们 注意 到 ， 这 桩 做 会 导致 类 似 的 相关 画 数 名 污染 
class namespace (类 名 字 空 间 ) 的 问题 。 然 而 他 们 仍然 同意 interface (接口 ) 和 oe 
implementation (HAREM) 应 该 被 分 开 。 他 们 是 怎样 解决 这 个 表面 上 的 矛盾 呢 ? 通过 利用 以 


下 事实 : pure virtual functions 〈 纯 虚拟 函数 ) 必须 在 concrete derived classes 〈 具 体 派 生 
类 ) 中 被 redeclared ( 重 声明 ) ， 但 是 它们 也 可 以 有 它们 自己 的 实现 。 以 下 就 是 Airplane 
hierarchy (继承 体系 ) 如 何 利 用 这 一 能 力 定义 一 个 pure virtual function 〈 纯 虚拟 函数 ) 


class Airplane { 
public: 
virtual void fly(const Airport& destination) = 0; 


T 


void Airplane: :fly(const Airport& destination) // an implementation of 
// a pure virtual function 
default code for flying an airplane to 
the given destination 
} 
class ModelA: public Airplane { 
public: 
virtual void fly(const Airport& destination) 
{ Airplane::fly(destination); } 


J; 

class ModelB: public Airplane { 

public: 
virtual void fly(const Airport& destination) 
{ Airplane::fly(destination); } 


}; 
class ModelC: public Airplane { 


public: 
virtual void fly(const Airport& destination); 


}; 
void ModelC::fly(const Airport& destination) 


code for flying a ModelC airplane to the given destination 


} 


除了 用 pure virtual function Aes 20) Airplane::fly 的 函数 体 代 替 了 独立 函数 
Airplane::defaultFly 之 外 ， 这 是 一 个 和 前 面 的 几乎 完全 相同 的 设计 。 本 质 上 ，fly 可 以 被 拆 成 
两 个 基本 组 件 。 它 的 declaration (声明 ) 指定 了 它 的 interface (接口 ) (这 是 derived 
classes (派生 类 ) 必须 使 用 的 ) ， 而 它 的 definition (定义 ) 指定 它 的 缺 省 行为 (这 

derived classes (派生 类 ) 可 以 使 用 的 ， 但 只 是 在 他 们 明确 要 求 这 一 点 时 ) 。 将 fly a 
defaultFly GH, Diss, (MAAKTAPRASHACANRY ERREN : 原来 是 
protected 的 代码 (通过 位 于 defaultFly 中 实现 ) 现在 成 为 public (因为 它 位 于 fly 中 ) 。 


最 后 ， 我 们 看 看 Shape 的 non-virtual function ( 非 虚 拟 男 数 ) , objectiD : 


class Shape { 
public: 
int objectID() const; 


}; 


当 一 个 member function (X A HŽ) 是 non-virtual ( 非 虚拟 的 ) 时 ， 不 应 该 指望 它 在 
derived classes (派生 类 ) 中 的 行为 会 有 所 不 同 。 实 际 上 ， 一 个 non-virtual member 
function (JER aA REGEX) 指定 了 一 个 invariant over specialization (超越 特殊 化 的 不 变 
量 ) ， 因 为 不 论 一 个 derived class (派生 类 ) 变 得 多 么 特殊 ， 它 都 把 它 看 作 是 不 允许 变化 的 
行为 。 如 下 所 指 除 的 ， 


声明 一 个 non-virtual function 〈 非 虚拟 函数 ) 的 目的 是 to have derived classes inherit a 
function interface as well as a mandatory implementation (使 派生 类 既 继 承 一 个 图 数 的 接 
口 ， 又 继承 一 个 强制 的 实现 ) 。 


你 可 以 这 样 考 虑 Shape::objectID 的 声明 , “每 一 个 Shape object 有 一 个 产生 object 

identifier (对 象 标识 码 ) ， 而 且 这 个 object identifier (对 象 标识 码 ) 总 是 用 同样 的 方法 计算 出 
来 的 ， 这 个 方法 是 由 Shape::objectID 的 定义 决定 的 ， 而 且 derived class (派生 类 ) 不 应 该 试 
图 改变 它 的 做 法 。" 因 为 一 个 non-virtual function (JER MAA) 被 看 作 一 个 invariant over 
specialization (超越 特殊 化 的 不 变量 ) ， 在 derived class (派生 类 ) 中 他 绝 不 应 该 被 重 定 
义 ， 细 节 的 讨论 参见 Item 36。 


对 pure virtual, simple virtual， 和 non-virtual functions 的 声明 的 不 同人 允许 你 精确 指定 你 需要 
derived classes (派生 类 ) 继承 什么 东西 。 分 别 是 interface only 〈 仅 有 接口 ) interface and 
a default implementation (接口 和 一 个 缺 省 的 实现 ) ， 和 interface and a mandatory 
implementation (接口 和 一 个 强制 的 实现 ) 。 因 为 这 些 不 同 的 声明 类 型 意味 着 根本 不 同 的 意 
义 ， 当 你 声明 你 的 member functions (kK ANB) 时 你 必须 在 它们 之 间 仔 细 地 选择 。 如 果 你 
这 样 做 了 ， 你 应 该 可 以 避免 由 缺乏 经 验 的 类 设计 者 造成 的 两 个 最 常见 的 错误 。 


第 一 个 错误 是 声明 所 有 的 函数 为 non-virtual ( 非 虚拟 ) 。 这 没有 给 derived classes (派生 
类 ) 的 特殊 化 留 出 空间 ; non-virtual destructors (JER HRM) 尤其 有 问题 (BM Item 
7) 。 当 然 ， 完 全 有 理由 设计 一 个 不 作为 base class ( 基 类 ) 使 用 的 类 。 在 这 种 情况 下 ， 一 套 
独 享 的 non-virtual member functions ( 非 虚拟 成 员 画 数 ) 是 完全 合理 的 。 然 而 ， 更 通常 的 情 
况 下 ， 这 样 的 类 既 可 能 出 于 对 virtual (虚拟 ) 和 non-virtual functions ( 非 虚 拟 画 数 ) 之 间 区 
别 的 无 知 ， 也 可 能 是 对 virtual functions (虚拟 画 数 ) 的 性 能 成 本 毫 无 根据 的 担心 的 结果 。 事 
实 是 ， 几 乎 任何 作为 base class ( 基 类 ) 使 用 的 类 都 会 有 virtual functions (虚拟 函数 ) (还 
是 参见 ltem 7) 。 


如 果 你 关心 virtual functions (虚拟 函数 ) 的 成 本 ， 请 允许 我 提起 基于 经 验 的 80-20 规则 (S 


见 Item 30) ， 在 一 个 典型 的 程序 中 的 情况 是 ，80% 的 运行 时 间 花 费 在 执行 其 中 的 20% 的 代 
码 上 。 这 个 规则 是 很 重要 的 ， 因 为 它 意 味 着 ， 平 均 下 来 ， 你 的 范 数 调用 中 的 80% 可 以 被 虚拟 


化 而 不 会 对 你 的 程序 的 整体 性 能 产生 哪怕 是 最 轻微 的 可 察觉 的 影响 。 在 你 走 进 对 “你 是 否 能 负 
担 得 起 一 个 virtual function (HAR) 的 成 本 "忧虑 的 阴影 之 前 ， 应 该 使 用 一 些 简单 的 预防 
措施 ， 以 确保 你 关注 的 是 你 的 程序 中 能 产生 决定 性 不 同 的 那 20%。 


另 一 个 常见 的 错误 声明 所 有 的 member functions (aw A WAX) 为 virtual (虚拟 ) 。 有 时 候 这 
样 做 是 正确 的 一 一 ltem 31 的 Interface classes (接口 类 ) 可 以 作为 证 据 。 然 而 ， 它 也 可 能 是 
缺乏 表明 态度 的 决心 的 类 设计 者 的 标志 。 某 些 函 数 在 derived classes (派生 类 ) 中 不 应 该 被 
重 定义 ， 而 且 只 要 在 这 种 情况 下 ， 你 都 应 该 通过 将 那些 函数 声明 为 non-virtual ( 非 虚拟 ) 而 
明确 地 表达 这 一 点 。 它 不 是 为 那些 人 服务 的 ， 他 们 假设 如 果 他 们 只 需 花 一 些 时 间 重 定义 你 的 
所 有 画 数 ， 你 的 类 就 会 被 所 有 的 人 用 来 做 所 有 的 事情 ， 如 果 你 有 一 个 invariant over 
specialization (超越 特殊 化 的 不 变量 ) ， 请 直 说 ， 不 必 害 怕 ! 


Things to Remember 


Inheritance of interface (接口 继承 ) 与 inheritance of implementation (实现 继承 ) 不 同 。 在 
public inheritance (公开 继承 ) 下 ，derived classes (派生 类 ) 总 是 继承 base class 
interfaces 〈 基 类 接口 ) 。 


Pure virtual functions (EWE) 指定 inheritance of interface only ( 仅 有 接口 被 继承 ) 。 


Simple (impure) virtual functions 《简单 虚拟 函数 ) 指定 inheritance of interface (接口 继承 ) 
加 上 inheritance of a default implementation ( 缺 省 实现 继承 ) 。 


Non-virtual functions (〈 非 虚拟 函数 ) 指定 inheritance of interface (接口 继承 ) 加 上 
inheritance of a mandatory implementation (强制 实现 继承 ) 。 


Item 35: 考虑 可 选 的 virtual functions (Hak 
数 ) 的 蔡 代 方法 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


现在 你 工作 在 一 个 视频 游戏 上 ， 你 在 游戏 中 为 角色 设计 了 一 个 hierarchy (继承 体系 ) 。 你 的 
游戏 中 有 着 变化 多 端的 恶劣 环境 ， 角 色 被 伤害 或 者 其 它 的 健康 状态 降低 的 情况 并 不 罕见 。 

此 你 决定 提供 一 个 member function (AX 4 EZ) healthValue， 它 返回 一 个 象征 角色 健康 状况 
如 何 的 整数 。 因 为 不 同 的 角色 计算 健康 值 的 方法 可 能 不 同 ， 将 healthValue 声明 为 virtual (Œ 
拟 ) 似乎 是 显而易见 的 设计 选择 : 


class GameCharacter { 
public: 
virtual int healthValue() const; // return character's health rating; 
ce // derived classes may redefine this 
}; 


healthValue 没有 被 声明 为 pure virtual ( 纯 虚 ) 的 事实 暗示 这 里 有 一 个 计算 健康 值 的 缺 省 算法 
(参见 ltem 34) 。 


这 确实 是 一 个 显而易见 的 设计 选择 ， 而 在 某 种 意义 上 ， 这 是 它 的 缺点 。 因 为 这 样 的 设计 过 于 
显而易见 ， 你 可 能 不 会 对 它 的 其 它 可 选 方法 给 予 足 够 的 关注 。 为 了 帮助 你 脱离 object-oriented 
design (面向 对 象 设计 ) 的 习惯 性 道路 ， 我 们 来 考虑 一 些 处 理 这 个 问题 的 其 它 方法 。 


The Template Method Pattern via the Non-Virtual Interface ldiom (经 由 非 虚拟 接口 惯用 法 实 
现 的 模板 方法 模式 ) 


我 们 以 一 个 主张 virtual functions (虚拟 图 数 ) 应 该 几乎 总 是 为 private (私有 的 ) 的 有 趣 观 点 
开始 。 这 一 观点 的 拥护 者 提出 : 一 个 较 好 的 设计 应 该 保留 作为 public member function (公有 
成 员 画 数 ) 的 healthValue， 但 点 将 它 改 为 non-virtual ( 非 虚拟 的 ) 并 让 它 调用 一 个 private 
virtual function 〈 私 有 虚拟 函数 ) 来 做 真正 的 工作 ， 也 就 是 说 ，doHealthValue : 


class GameCharacter { 


public: 
int healthValue() const // derived classes do not redefine 
// this - see Item 36 
// do "before" stuff - see below 
int retVal = doHealthValue(); // do the real work 


// do "after" stuff - see below 


return retVal; 


private: 


virtual int doHealthValue() const // derived classes may redefine this 
{ 
hee // default algorithm for calculating 
} // character's health 
3; 


在 这 个 代码 (以 及 本 ltem 的 其 它 代 码 ) 中 ， 我 在 类 定义 中 展示 member functions (AK AH 
数 ) 的 本 体 。 就 像 Item 30 中 所 解释 的 ， 这 会 将 它们 隐 式 声明 为 inline (AK) 。 我 用 这 种 方 
法 展示 代码 仅仅 是 这 样 更 易于 看 到 它 在 做 些 什 么 。 我 所 描述 的 设计 与 是 否 inline 化 无 关 ， 所 以 
不 必 深 究 member functions (AK AWM) 定义 在 类 的 内 部 有 什么 意味 深长 的 含义 。 根 本 没 
有 。 





这 个 基本 的 设计 让 客户 通过 public non-virtual member functions (公有 非 虚拟 成 员 函 
数 ) 调用 private virtual functions 〈 私 有 虚拟 函数 ) 一 一 被 称 为 non-virtual interface (NVI) 
idiom ( 非 虚拟 接口 惯用 法 ) 。 这 是 一 个 更 通用 的 被 称 为 Template Method (一 个 模式 ， 很 不 
=, 5 C++ templates (模板 ) Æ) 的 design pattern (设计 模式 ) 的 特殊 形式 。 我 将 那个 
non-virtual function 〈 非 虚拟 函数 ) (例如 ，healthValue) 称 为 virtual function's 

wrapper 〈 虚 拟 本 数 的 外 壳 ) 。 


NVI idiom (惯用 法 ) 的 一 个 优势 通过 "do 'before' stuff" 和 "do 'after stuff" 两 个 注释 在 代码 中 
标示 出 来 。 这 些 注释 标 出 的 代码 片断 在 做 真正 的 工作 的 virtual function (虚拟 函数 ) 之 前 或 之 
后 调用 。 这 就 意味 着 那个 wrapper (AF) 可 以 确保 在 virtual function (虚拟 函数 ) 被 调用 
前 ， 特 定 的 背景 环境 被 设置 ， 而 在 调用 结束 之 后 ， 这 些 背 景 环 境 被 清理 。 例 如 ，"before" stuff 
可 以 包括 锁 闭 一 个 mutex (EFF) ， 生 成 一 条 日 志 条 目 ， 校 验 类 变量 和 男 数 的 
preconditions (前 提 条 件 ) 是 否 被 满足 ， 等 等 。"after" stuff 可 以 包括 解锁 一 个 mutex (AR 
体 ) , BARZ postconditions (结束 条 件 ) ， 类 不 变量 的 恢复 ， 等 等 。 如 果 你 让 客户 直接 
调用 virtual functions (EWR) ， 确 实 没 有 好 的 方法 能 够 做 到 这 些 。 


涉及 derived classes (派生 类 ) HES private virtual functions (私有 虚拟 函数 ) (这 些 重 定 
LKA ENTRA ! ) 的 NVIidiom 可 能 会 搅乱 你 的 头脑 。 这 里 没有 设计 上 的 矛盾 。 重 定义 
一 个 virtual function (Hw) 指定 如 何 做 某 些 事 。 调 用 一 个 virtual function (sae) 
指定 什么 时 候 去 做 。 互 相 之 间 没 有 关系 。NVIidiom 人 允许 derived classes (派生 类 ) 重 定义 一 
+ virtual function (zw) ， 这 样 就 给 了 它们 控制 功能 如 何 实 现 的 能 力 ， 但 是 base 


class ( 基 类 ) RE TAERU RAR F- ARAI, (he C++ 规定 derived 
classes (派生 类 ) 可 以 重 定义 private inherited virtual functions (#\A AIH it 2 45 SI 
数 ) 是 非常 明智 的 。 


在 NVI idiom 之 下 ，virtual functions 《虚拟 函数 ) 成 为 private (私有 的 ) 并 不 是 绝对 必需 
的 。 在 一 些 class hierarchies (类 继承 体系 ) 中 ， 一 个 virtual function (we) 的 
derived class (派生 类 ) 实现 被 期 望 调 用 其 base class ( 基 类 ) 的 对 应 物 (例如 ， 第 120 页 
的 例子 ) ， 而 为 了 这 样 的 调用 能 够 合法 ， 虚 拟 必须 成 为 protected (保护 的 ) ， 而 非 

private (私有 的 ) 。 有 时 一 个 virtual function 〈 虚 拟 范 数 ) 其 至 必须 是 public (AAR) (AI 
如 ，polymorphic base classes (多 态 基 类 ) 中 的 destructors (AT 4 ER) 
7) ， 但 这 样 一 来 NVI idiom 就 不 能 被 真正 应 用 。 


参见 ltem 





The Strategy Pattern via Function Pointers (经 由 画 数 指针 实现 的 策略 模式 ) 


NVI idiom Æ public virtual functions (公有 虚拟 函数 ) 的 有 趣 的 可 选 苦 代 物 ， 但 从 设计 的 观点 
来 看 ， 它 比 装 点 门 也 多 不 了 多 少 东 西 。 半 竟 ， 我 们 还 是 在 用 virtual functions (mM) 来 
计算 每 一 个 角色 的 健康 值 。 一 个 更 引 人 注 目的 设计 主张 认为 计算 一 个 角色 的 健康 值 不 依赖 于 

角色 的 类 型 一 一 这 样 的 计算 根本 不 需要 成 为 角色 的 一 部 分 。 例 如 ， 我 们 可 能 需要 为 每 一 个 角 

色 的 constructor (4316) 传递 一 个 指向 健康 值 计 算 画 数 的 指针 ， 而 我 们 可 以 调用 这 个 画 
数 进行 实际 的 计算 : 


class GameCharacter; // forward declaration 


// function for the default health calculation algorithm 
int defaultHealthCalc(const GameCharacter& gc); 


class GameCharacter { 
public: 
typedef int (*HealthCalcFunc) (const GameCharacter&) ; 


explicit GameCharacter(HealthCalcFunc hcf = defaultHealthCalc) 
: healthFunc(hcf) 
{} 


int healthValue() const 
{ return healthFunc(*this); } 


private: 
HealthCalcFunc healthFunc; 


了 


这 个 方法 是 另 一 个 通用 design pattern (设计 模式 ) — Strategy 的 简单 应 用 ， 相 对 于 基于 
GameCharacter hierarchy (继承 体系 ) 中 的 virtual functions (虚拟 函数 ) 的 方法 ， 它 提供 了 
某 些 更 引 人 注 目的 机 动 性 : 


。 相同 角色 类 型 的 不 同 实例 可 以 有 不 同 的 健康 值 计算 画 数 。 例 如 : 


class EvilBadGuy: public GameCharacter { 
public: 

explicit EvilBadGuy(HealthCalcFunc hcf = defaultHealthCalc) 
: GameCharacter (hcf) 


of ane aay 
int loseHealthQuickly(const GameCharacter&) ; // health calculation 
int loseHealthSlowly(const GameCharacter&); // funcs with different 
// behavior 
EvilBadGuy ebg1(loseHealthQuickly) ; // same-type charac- 
EvilBadGuy ebg2(loseHealthSlowly) ; // ters with different 


// health-related 
// behavior 


。 4 F- -DEENA BRR ANSWRME. GMM, GameCharacter 可 以 
提供 一 个 member function (AK A 2X) setHealthCalculator， 它 被 允许 代替 当前 的 健康 
t RRR 


在 另 一 方面 ， 健 康 值 计算 函数 不 再 是 GameCharacter hierarchy (继承 体系 ) 的 一 个 member 
function (成 员 画 数 ) 的 事实 ， 意 味 着 它 不 再 拥有 访问 它 所 计算 的 那个 对 象 内 部 构件 的 特权 。 
例如 ，defaultHealthCalc 不 能 访问 EvilBadGuy 的 non-public ( 非 公有 ) 构件 。 如 果 一 个 角色 
的 健康 值 计算 能 够 完全 基于 通过 角色 的 public interface (公有 接口 ) 可 以 得 到 的 信息 ， 这 就 
没什么 问题 ， 但 是 ， 如 果 准 确 的 健康 值 计算 需要 non-public ( 非 公有 ) 信息 ， 就 会 有 问题 。 实 
际 上 ， 在 任何 一 个 你 要 用 class (类 ) 外 部 的 等 价 机 能 (例如 ， 经 由 一 个 non-member non- 
friend function ( 非 成 员 非 友 元 函数 ) 或 经 由 另 一 个 class (类 ) 的 non-friend member 
function (JER IT A KAO ) KB class (类 ) 内 部 的 机 能 (例如 ， 经 由 一 个 member 
function (成 员 函 数 ) ) 的 时 候 ， 它 都 是 一 个 潜在 的 问题 。 这 个 问题 将 持续 影响 本 Item BYR 
余部 分 ， 因 为 所 有 我 们 要 考虑 的 其 它 设计 选择 都 包括 GameCharacter hierarchy (继承 体系 ) 
的 外 部 男 数 的 使 用 。 


作为 一 个 通用 规则 ， 解 决 对 ‘non-member functions (JER A ESA) 对 类 的 non-public ( 非 公 
A) 构件 的 访问 的 需要 ”的 唯一 方法 就 是 削弱 类 的 encapsulation (封装 性 ) 。 例 如 ， 

class (类 ) 可 以 将 non-member functions (JERR A RX) 声明 为 friends ( 友 元 ) ， 或 者 ， 它 
可 以 提供 对 “在 其 它 情况 下 它 更 希望 保持 隐藏 的 本 身 的 实现 部 分 "的 public accessor 

functions (公有 访问 者 函数 ) 。 使 用 一 个 function pointer (WAHEH) 代替 一 个 virtual 
function (HW) 的 优势 (例如 ， 具 有 逐 对 象 健康 值 计 算 函 数 的 能 力 和 在 运行 时 改变 这 样 
的 函数 的 能 力 ) 是 否 能 抵消 可 能 的 降低 GameCharacter 的 encapsulation (封装 性 ) 的 需要 
是 你 必须 在 设计 时 就 做 出 决定 的 重要 部 分 。 


The Strategy Pattern via tr1::function (经 由 tr1::function 实现 的 策略 模式 ) 


一 旦 你 习惯 了 templates (模板 ) 和 implicit interfaces (HHA) (参见 ltem 41) 的 应 
用 ，function-pointer-based (基于 函数 指针 ) 的 方法 看 上 去 就 有 些 死板 了 。 健 康 值 的 计算 为 
什么 必须 是 一 个 function (ER) ， 而 不 能 是 某 种 简单 的 行为 类 似 function (HR) 的 东西 


(例如 ， 一 个 function object (HAR) ) ? 如 果 
不 能 是 一 个 member function (AK AER) ?为 什么 
型 为 int 的 类 型 ? 


它 必须 是 一 个 function (HR) ， 为 什么 
它 必须 返回 一 个 int， 而 不 是 某 种 能 够 转 
如 果 我 们 用 一 个 tr1::function 类 型 的 对 象 代替 一 个 function pointer (AHHH) (诸如 
healthFunc) ， 这 些 约 束 就 会 消失 。 就 像 Item 54 中 的 解释 ， 这 样 的 对 象 可 以 持 有 any 
callable entity (任何 可 调用 实体 ) (例如 ，function pointer (ŽE #4) ，function 

object (Ist) ， 或 member function pointer (WX A RGS 4) ) ， 这 些 实体 的 标志 性 特 
征 就 是 兼容 于 它 所 期 待 的 东西 。 我 们 马上 就 会 看 到 这 样 的 设计 ， 这 次 使 用 了 tr1::function : 


class GameCharacter; // as before 
int defaultHealthCalc(const GameCharacter& gc); // as before 


class GameCharacter { 
public: 
// HealthCalcFunc is any callable entity that can be called with 
// anything compatible with a GameCharacter and that returns anything 
// compatible with an int; see below for details 
typedef std::tri::function<int (const GameCharacter&)> HealthCalcFunc; 
explicit GameCharacter(HealthCalcFunc hcf = defaultHealthCalc) 
: healthFunc(hcf ) 
{} 


int healthValue() const 
{ return healthFunc(*this); } 


private: 
HealthCalcFunc healthFunc; 
}; 


就 像 你 看 到 的 ，HealthCalcFunc 是 一 个 tr1::function instantiation (实例 化 ) 的 typedef, ix 


意味 着 它 的 行为 类 似 一 个 普通 的 function pointer (函数 指针 ) 类 型 。 我 们 近 距 离 看 看 
HealthCalcFunc 究竟 是 一 个 什么 东西 的 typedef : 


std::tri::function<int (const GameCharacter&)> 


这 里 我 突出 了 这 个 tr1::function instantiation ele 的 “target signature (目标 识别 特 


征 ) ”。 这 个 target signature (目标 识别 特征 ) 是 “取得 一 个 引 向 const GameCharacter 的 
reference (引用 ) ， 并 返回 一 个 int 的 函数 "。 ‘function 类 型 的 (例如 ， 


HealthCalcFunc 类 型 的 ) 对 象 可 以 持 有 兼容 于 这 个 target signature (目标 识别 特征 ) 的 any 
callable entity (任何 可 调用 实体 ) 。 兼 容 意味 着 这 个 实体 的 参数 能 够 隐 式 地 转型 为 一 个 const 
GameCharacter&， 而 它 的 返回 类 型 能 够 隐 式 地 转型 为 一 个 into 


与 我 们 看 到 的 最 近 一 个 设计 (在 那里 GameCharacter 持 有 一 个 指向 一 个 画 数 的 指针 ) FELL, 
这 个 设计 几乎 相同 。 仅 有 的 区 别 是 目前 的 GameCharacter 持 有 一 个 tr1::function 对 象 一 一 指 
向 一 个 函数 的 generalized ee) 指针 。 除 了 达到 “clients (客户 ) 在 指定 健康 值 计算 函数 
时 有 更 大 的 灵活 性 ”的 效果 之 外 ， 这 个 变化 是 如 此 之 小 ， 以 至 于 我 宁愿 对 它 视而不见 





short calcHealth(const GameCharacter&); // health calculation 
// function; note 
// non-int return type 


struct HealthCalculator { // class for health 
int operator()(const GameCharacter&) const // calculation function 
stones «4s // objects 

}; 

class GameLevel { 

public: 
float health(const GameCharacter&) const; // health calculation 
oie // mem function; note 

ioe // non-int return type 

class EvilBadGuy: public GameCharacter { // as before 

}; 

class EyeCandyCharacter: public GameCharacter { // another character 
aay // type; assume same 

We // constructor as 


// EvilBadGuy 


EvilBadGuy ebg1(calcHealth) ; // character using a 
// health calculation 
// function 


EyeCandyCharacter ecc1(HealthCalculator()); // character using a 
// health calculation 
// function object 


GameLevel currentLevel; 


EvilBadGuy ebg2( // character using a 
std::tri::bind(&GameLevel: :health, // health calculation 
currentLevel, // member function; 
_1) // see below for details 


就 个 人 感觉 而 言 : 我 发 现 tr1::function 能 让 你 做 的 事情 是 如 此 让 人 惊喜 ， 它 全 我 浑身 兴奋 异 
常 。 如 果 你 没有 感到 兴奋 ， 那 可 能 是 因为 你 正 目不转睛 地 上 果 着 ebg2 的 定义 并 对 tr1::bind 的 
调用 会 发 生 什么 迷惑 不 解 。 请 耐心 地 听 我 解释 。 


比方 说 我 们 要 计算 ebg2 的 健康 等 级 ， 应 该 使 用 GameLevel class (类 ) 中 的 health member 
function (a AES) 。 现 在 ，GameLevel::health 是 一 个 被 声明 为 取得 一 个 参数 (一 个 引 向 
GameCharacter 的 引用 ) 的 函数 ， 但 是 它 实际 上 取得 了 两 个 参数 ， 因 为 它 同 时 得 到 一 个 隐 式 
的 GameLevel 参数 一 一 指向 this。 然 而 ，GameCharacters 的 健康 值 计 算 画 数 只 取得 单一 的 
参数 : 将 被 计算 健康 值 的 GameCharacter。 如 果 我 们 要 使 用 GameLevel::health 计算 ebg2 
的 健康 值 ， 我 们 必须 以 某 种 方式 “改造 " 它 ， 以 使 它 适应 只 取得 唯一 的 参数 (一 个 
GameCharacter) ， 而 不 是 两 个 (一 个 GameCharacter 和 一 个 GameLevel) 。 在 本 例 中 ， 
我 们 总 是 要 使 用 currentLevel 作为 GameLevel 对 象 来 计算 ebg2 的 健康 值 ， 所 以 每 次 调用 
GameLevel::health 计算 ebg2 的 健康 值 时 ， 我 们 就 要 "bind" CRE) currentLevel 来 作为 
GameLevel 的 对 象 来 使 用 。 这 就 是 tr1::bind 的 调用 所 做 的 事情 : 它 指定 ebg2 的 健康 值 计算 
函数 应 该 总 是 使 用 currentLevel 作为 GameLevel 对 象 。 





我 们 跳 过 一 大 堆 的 细节 ， 诸 如 为 什么 ”1" 意味 着 “ 当 为 了 ebg2 调用 GameLevel::health 时 使 
用 currentLevel 作为 GameLevel 对 象 "。 这 样 的 细节 并 没有 什么 启发 性 ， 而 且 它 们 将 转移 我 
所 关注 的 基本 点 : 在 计算 一 个 角色 的 健康 值 时 ， 通 过 使 用 tr1::function 代替 一 个 function 
pointer (HAHH) ， 我 们 将 允许 客户 使 用 any compatible callable entity (任何 兼容 的 可 调 
用 实体 ) 。 很 酷 是 不 是 ? 


The "Classic" Strategy Pattern (“经 典 的 "策略 模式 ) 
如 果 你 比 C++ 更 加 深入 地 进入 design patterns (设计 模式 ) ， 一 个 Strategy 的 更 加 习以为常 
的 做 法 是 将 health-calculation function (健康 值 计 算 男 数 ) 做 成 一 个 独立 的 health-calculation 


hierarchy (健康 值 计 算 继 承 体系 ) 的 virtual member function (HIM ARAL) 。 做 成 的 
hierarchy (继承 体系 ) 设计 看 起 来 就 像 这 样 : 











EyeCandyCharacter | FastHealthLoser | 


如 果 你 不 熟悉 UML 记 法 ， 这 不 过 是 在 表示 当 把 EvilBadGuy 和 EyeCandyCharacter 作为 
derived classes (派生 类 ) 时 ，GameCharacter 是 这 个 inheritance hierarchy (继承 体系 ) 的 
根 ; HealthCalcFunc 是 另 一 个 带 有 derived classes (派生 类 ) SlowHealthLoser 和 
FastHealthLoser 的 inheritance hierarchy (继承 体系 ) 的 根 ; 而 每 一 个 GameCharacter 类 型 
的 对 象 包含 一 个 指向 “从 HealthCalcFunc 派生 的 对 象 "的 指针 。 


这 就 是 相应 的 框架 代码 : 


class GameCharacter; // forward declaration 


class HealthCalcFunc { 
public: 


virtual int calc(const GameCharacter& gc) const 


ate 


}; 
HealthCalcFunc defaultHealthCalc; 


class GameCharacter { 

public: 
explicit GameCharacter(HealthCalcFunc *phcf = &defaultHealthCalc) 
: pHealthCalc(phcf ) 
{} 


int healthValue() const 
{ return pHealthCalc->calc(*this);} 


private: 
HealthCalcFunc *pHealthCalc; 
}; 
个 方法 的 吸引 力 在 于 对 于 熟悉 “标准 的 "Strategy pattern (策略 模式 ) 实现 的 人 可 以 很 快 地 识 


再 加 上 它 提 供 了 通过 在 HealthCalcFunc hierarchy (继承 体系 ) 中 增加 一 个 derived 
class (派生 类 ) 而 微调 已 存在 的 健康 值 计 算 算法 的 可 能 性 。 


Summary (概要 ) 


这 个 Item 的 基本 建议 是 当 你 为 尝试 解决 的 问题 寻求 一 个 设计 时 ， 你 应 该 考虑 可 选 的 virtual 
functions (虚拟 函数 ) 的 替代 方法 。 以 下 是 对 我 们 考察 过 的 可 选 方法 的 一 个 简略 的 回顾 : 


e 使 用 non-virtual interface idiom (NVI idiom) ( 非 虚拟 接口 惯用 法 ) ， 这 是 用 public non- 
virtual member functions (AA FER PLAN A ENR) 包装 可 访问 权限 较 小 的 virtual 
functions (sz 4.E42%) 的 Template Method design pattern (模板 方法 模式 ) 的 一 种 形 
式 。 

e 用 function pointer data members (ÄUS H AER A) 代替 virtual functions (H+ 
#1) ， 一 种 Strategy design pattern (策略 模式 ) 的 显而易见 的 形式 。 


e 用 tr1::function data members (数据 成 员 ) 代替 virtual functions (虚拟 画 数 ) ， 这 样 就 
允许 使 用 兼容 于 你 所 需要 的 东西 的 any callable entity (任何 可 调用 实体 ) 。 这 也 是 
Strategy design pattern (策略 模式 ) 的 一 种 形式 。 


e 用 virtual functions in another hierarchy (另外 一 个 继承 体系 中 的 虚拟 函数 ) RE virtual 
functions in one hierarchy 《单独 一 个 继承 体系 中 的 虚拟 函数 ) 。 这 是 Strategy design 
pattern 〈 策 略 模式 ) 的 习以为常 的 实现 。 


这 不 是 一 个 可 选 的 virtual functions (虚拟 函数 ) 的 替代 设计 的 详尽 无 遗 的 列表 ， 但 是 它 足 以 
使 你 确信 这 些 是 可 选 的 方法 。 此 外 ， 它 们 之 间 互 为 比较 的 优 劣 应 该 使 你 考虑 它们 时 更 为 明 
确 。 


为 了 避免 陷入 object-oriented design (面向 对 象 设计 ) 的 习惯 性 道路 ， 时 不 时 地 给 车 轮 一 些 
有 益 的 颠 艇 。 有 很 多 其 它 的 道路 。 值 得 花 一 些 时 间 去 考虑 它们 。 


Things to Remember 


可 选 的 virtual functions (虚拟 图 数 ) 的 替代 方法 包括 NVI 惯用 法 和 Strategy design 
pattern (策略 模式 ) 的 各 种 变化 形式 。NVI 惯用 法 本 身 是 Template Method design 
pattern (模板 方法 模式 ) 的 一 个 实例 。 


将 一 个 机 能 从 一 个 member function (AK A ER) 中 移 到 class (类 ) 之 外 的 某 个 函数 中 的 一 
个 危害 是 non-member function (JEX 7 BR) 没有 访问 类 的 non-public members ( 非 公有 
成 员 ) 的 途径 。 


tr1::function 类 似 generalized function pointers ( 泛 型 化 的 函数 指针 ) 。 这 样 的 对 
象 支持 所 有 兼容 于 一 个 给 定 的 目标 特征 的 callable entities (可 调用 实体 ) 。 


Item 36: 绝 不 要 重 定 义 一 个 inherited non-virtual 
function (通过 继承 得 到 的 非 虚拟 函数 ) 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


假设 我 告诉 你 class (#) D M class (#) B publicly derived (公有 继承 ) ， 而 且 在 
class (类 ) B 中 定义 了 一 个 public member function (AAR ABE) mfo mf 的 参数 和 返回 
值 类 型 是 无 天 紧要 的 ， 所 以 我 们 就 假设 它们 都 是 void。 换 名 话说， 我 的 意思 是 : 


class B { 
public: 
void mf(); 


}; 
class D: public B { ... }; 


甚至 不 必 知 道 关 于 B，D， 或 mf 的 任何 事情 ， 给 定 一 个 类 型 为 D 的 object (st) x, 


D x; // x is an object of type D 


对 此 你 或 许 非 常 吃惊 ， 


B *pB = &x; // get pointer to x 


pB->mf(); // call mf through pointer 


的 行为 不 同 于 以 下 代码 : 


D *pD = &x; // get pointer to x 


pD->mf(); // call mf through pointer 


因为 在 两 种 情况 中 ， 你 都 调用 了 object (xt) x 中 的 member function (AK A ERX) mf. 
为 两 种 情况 中 都 是 同样 的 function (W2) 和 同样 的 object (HR) ， 它 们 的 行为 应 该 有 相同 
的 方式 ， 对 吗 ? 


是 的 ， 应 该 。 但 是 也 可 能 不 ， 特 别 地 ， 如 果 mf 是 non-virtual ( 非 虚拟 ) 而 D 定义 了 它 自己 的 
版 本 的 mf : 


class D: public B { 


public: 
void mf(); // hides B::mf; see Item33 
J; 
pB->mf(); // calls B::mf 
pD->mf(); // calls D::mf 


这 种 行为 两 面 性 的 原因 是 像 B::mf 和 D::mf 这 样 的 non-virtual functions 〈 非 虚拟 函数 ) = 
statically bound (静态 绑 定 ) 的 (参见 Item 37) 。 这 就 意味 着 因为 pB 被 声明 为 pointer-to-B 
类 型 ， 所 以 ， 即 使 就 像 本 例 中 的 做 法 ， 让 pB 指向 一 个 从 B 继承 的 类 的 对 象 ， 通 过 pB 调用 的 
non-virtual functions (JERR) 也 总 是 定义 在 class B 中 的 那 一 个 。 


在 另 一 方面 ，virtual functions (虚拟 函数 ) 是 dynamically bound (动态 绑 定 ) 的 (再 次 参见 
Item 37) ， 所 以 它们 不 会 发 生 这 个 问题 。 如 果 mf 是 一 个 virtual function (虚拟 函数 ) ， 无 论 
通过 pB 还 是 pD 调用 mf 都 将 导致 D::mf 的 调用 ， 因 为 pB 和 pD 都 实际 地 指向 一 个 

type (类 型 ) D 的 object (对 象 ) 。 


如 果 你 在 编写 class D 而 且 你 重 定义 了 一 个 你 从 class B 继承 到 的 non-virtual function (JER 
PNR) mf, DA objects 〈 对 象 ) 将 很 可 能 表现 出 不 协调 的 行为 。 特 别 是 ， 当 mif 被 调用 
时 ， 任 何 给 定 的 D object (对 象 ) 的 行为 既 可 能 像 B 也 可 能 像 D， 而 且 决 定 因素 与 

object (4R) 本 身 无 关 ， 但 是 和 指向 它 的 pointer (指针 ) 的 声明 类 型 有 关 。references ( 引 
FA) 也 会 像 pointers (指针 ) 一 样 表现 出 莫名 其 妙 的 行为 。 


但 这 仅仅 是 一 个 从 实用 出 发 的 论据 。 我 知道 ， 你 真正 需要 的 是 不 能 重 定义 inherited non- 
virtual functions (通过 继承 得 到 的 非 虚 拟 函 数 ) 的 理论 上 的 理由 。 我 很 愿意 效劳 。 


Item 32 解释 了 public inheritance (公有 继承 ) 意味 着 is-a，ltem 34 记述 了 为 什么 在 一 个 
class (类 ) 中 声明 一 个 non-virtual function (JER MN) 是 为 这 个 class (类 ) 设 定 一 个 
invariant over specialization (超越 特殊 化 的 不 变量 ) ， 如 果 你 将 这 些 经 验 应 用 于 

classes (#) B 和 D 以 及 non-virtual member function (JER IH) B::mf， 那 么 : 


每 一 件 适 用 于 B objects (对 象 ) 的 事情 也 适用 于 D objects (4R) ， 因 为 每 一 个 objects 
都 is-a (是 一 个 ) D objects (对 象 ) ; 


M B 继承 的 classes (类 ) 必须 同时 继承 mf 的 interface (接口 ) 和 implementation ( 实 
现 ) ， 因 为 mf 在 B 中 是 non-virtual ( 非 虚 拟 ) 的 。 


现在 ， 如 果 D 重 定义 mf， 你 的 设计 中 就 有 了 一 处 矛盾 。 如 果 D 真 的 需要 实现 不 同 于 B 的 
mf， 而 且 如 果 每 一 个 B objects (对 象 ) 无 论 如 何 特殊 一 一 都 必须 使 用 B 对 mf 的 实现 ， 
那么 每 一 个 D 都 is-a (是 一 个 ) B 就 完全 不 成 立 。 在 那 种 情况 下 ，D 就 不 应 该 从 B publicly 
inherit (公有 继承 ) 。 另 一 方面 ， 如 果 D 真 的 必须 从 B publicly inherit (公有 继承 ) ， 而 且 如 
R D 真 的 需要 实现 不 同 于 B 的 mf， 那么 mf 反映 了 一 个 B 的 invariant over 

specialization (超越 特殊 化 的 不 变量 ) 就 不 会 成 立 。 在 那 种 情况 下 ，mf 应 该 是 virtual (È 





拟 ) 的 。 最 后 ， 如 果 每 一 个 D 真 的 都 is-a (是 一 个 ) B, MAUR mf 真 的 相当 于 一 个 B 的 
invariant over specialization (超越 特殊 化 的 不 变量 ) ， 那 么 D 就 不 会 真 的 需要 重 定义 mf， 而 
且 想 都 不 能 想 。 


管 使 用 那 一 条 规则 ， 必 须 做 出 某 些 让 步 ， 而 且 无 条 件 地 禁止 重 定义 一 个 inherited non- 
virtual function 〈 通 过 继承 得 到 的 非 虚拟 函数 ) 。 


如 果 阅 读 这 个 Item 给 你 déjà vu ( 似 鲁 相识 ) 的 感觉 ， 那 可 能 是 因为 你 已 经 阅读 了 ltem 7， 
那个 Item 解释 了 为 什么 polymorphic base classes (多 态 基 类 ) 中 的 destructors (#1 4H 
数 ) 应 该 是 virtual (虚拟 ) 的 。 如 果 你 违反 了 那个 guideline (指导 方针 ) 例如， 如 果 你 在 
一 个 polymorphic base class (多 态 基 类 ) 中 声明 一 个 non-virtual destructor ( 非 虚拟 析 构 汞 
数 ) ) ， 你 也 同时 违反 了 这 里 这 个 guideline (指导 方针 ) ， 因 为 derived classes (派生 类 ) 
总 是 要 重 定义 一 个 inherited non-virtual function (通过 继承 得 到 的 非 虚拟 函数 ) : base 
class ( 基 类 ) 的 destructor ( 析 构 范 数 ) 。 甚 至 对 于 没有 声明 destructor ( 析 构 函数 ) 的 
derived classes (派生 类 ) 这 也 是 成 立 的 ， 因 为 ， 就 像 ltem 5 的 解释 ，destructor (ATM 
数 ) 是 一 个 “如 果 你 没有 定义 你 自己 的 ， 编 译 器 就 会 为 你 生成 一 个 ”的 member functions (成 员 
WA) 。 其 实 ，ltem 7 只 相当 于 本 ltem 的 一 个 特殊 情况 ， 尽 管 它 重要 到 足以 把 它 提 出 来 独立 
成 篇 。 

Things to Remember 


绝 不 要 重 定 义 一 个 inherited non-virtual function (通过 继承 得 到 的 非 虚 拟 函 数 ) 。 


Item 37: 绝 不 要 重 定 义 一 个 函数 的 inherited 
default parameter value (通过 继承 得 到 的 缺 省 参 
数值 ) 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


我 们 直接 着 手 简化 这 个 话题 。 只 有 两 种 函数 能 被 你 inherit (继承 ) : virtual (虚拟 的 ) 和 
non-virtual ( 非 虚拟 的 ) 。 然 而 ， 重 定义 一 个 inherited non-virtual function (通过 继承 得 到 的 
JER DWM) 永远 都 是 一 个 错误 (SM Item 36) ， 所 以 我 们 可 以 安全 地 将 我 们 的 讨论 限制 在 
你 继承 了 一 个 virtual function with a default parameter value ( 带 有 一 个 缺 省 参数 值 的 虚拟 画 
数 ) 的 情形 。 


在 这 种 情况 下 ， 本 Item 的 理由 就 变 得 非常 地 直截了当 : virtual functions (Hwa) 是 
dynamically bound (动态 绑 定 ) ， 而 default parameter values ( 缺 省 参数 值 ) 是 statically 
bound (AHE) 。 


那 又 怎样 呢 ? 你 说 static (静态 ) 和 dynamic binding (HARE) 之 间 的 区 别 早已 塞 入 你 负 
担 过 重 的 头脑 ? (不 要 忘 了 ，static binding (FARE) 也 以 early binding (前 期 绑 定 ) 闻 
名 ， 而 dynamic binding (动态 绑 定 ) 也 以 late binding (SHAS) AS. ) 那么 ， 我 们 就 再 
来 回顾 一 下 。 


一 个 object (对 象 ) 的 static type (静态 类 型 ) 就 是 你 在 程序 文本 中 声明 给 它 的 type (类 
型 ) 。 考 虑 这 个 class hierarchy (类 继承 体系 ) 


// a Class for geometric shapes 
class Shape { 
public: 
enum ShapeColor { Red, Green, Blue }; 


// all shapes must offer a function to draw themselves 
virtual void draw(ShapeColor color = Red) const = 0; 


T 


class Rectangle: public Shape { 

public: 
// notice the different default parameter value — bad! 
virtual void draw(ShapeColor color = Green) const; 


}; 
class Circle: public Shape { 


public: 
virtual void draw(ShapeColor color) const; 


Ta 


直观 地 看 ， 它 看 起 来 就 像 这 个 祥子 : 








Rectangle Circle 


现在 考虑 这 些 pointers (指针 ) 


Shape *ps; // static type = Shape* 
Shape *pc = new Circle; // static type = Shape* 
Shape *pr = new Rectangle; // static type = Shape* 


EAI, ps, pc 和 pr 全 被 声明 为 pointer-to-Shape 类 型 ， 所 以 它们 全 都 以 此 作为 它们 的 
static type (静态 类 型 ) 。 注 意 这 就 使 得 它们 真正 指向 的 东西 完全 没有 区 别 E 论 如 何 ， 它 
们 的 static type (静态 类 型 ) 都 是 Shape*。 














一 个 object (对 象 ) 的 dynamic type (动态 类 型 ) 取决 于 它 当 前 引用 的 object (对 象 ) 的 
type (类 型 ) 。 也 就 是 说 ， 它 的 dynamic type (动态 类 型 ) 表明 它 有 怎样 的 行为 。 在 上 面 的 
例子 中 ，pc 的 dynamic type (动态 类 型 ) 是 Circle*， 而 pr 的 dynamic type (动态 类 型 ) 
Rectangle*。 至 于 ps， 它 没有 一 个 实际 的 dynamic type (动态 类 型 ) ， 因 为 它 (还 ) 不 能 
用 任何 object (对 象 ) 。 


dynamic types (动态 类 型 ) ， 就 像 它 的 名 字 所 暗示 的 ， 能 在 程序 运行 中 变化 ， 特 别 是 通过 
assignments (赋值 ) 
ps = pc; // ps's dynamic type is 
// now Circle* 


ps = pr; // ps's dynamic type is 
// now Rectangle* 


virtual functions (虚拟 函数 ) 是 dynamically bound (动态 绑 定 ) ， 意 味 着 被 调用 的 特定 函数 
取决 于 被 用 来 调用 它 的 那个 object (对 象 ) 的 dynamic type (动态 类 型 ) 


pc->draw(Shape: :Red); // calls Circle::draw(Shape: :Red) 


pr->draw(Shape: :Red); // calls Rectangle: :draw(Shape: :Red) 


我 知道 ， 这 全 是 老生 常 谈 ; 你 的 确 已 经 理解 了 virtual functions (虚拟 画 数 ) 。 但 是 ， 当 你 考 
虑 virtual functions with default parameter values 〈 带 有 缺 省 参数 值 的 虚拟 范 数 ) 时 ， 就 全 乱 
了 套 ， 因 为 ， 如 上 所 述 ，virtual functions (+E) 是 dynamically bound (动态 绑 定 ) ， 
但 default parameters ( 缺 省 参数 ) Æ statically bound (静态 绑 定 ) 。 这 就 意味 着 你 最 终 调 用 
了 一 个 定义 在 derived class (派生 类 ) 中 的 virtual function (虚拟 函数 ) 却 使 用 了 一 个 来 自 
base class ( 基 类 ) 的 default parameter value (人 缺 省 参数 值 ) 。 


pr->draw(); // calls Rectangle: :draw(Shape: :Red)! 


在 此 情况 下 ，pr 的 dynamic type (动态 类 型 ) 是 Rectangle*， 所 以 正 像 你 所 希望 的 ， 
Rectangle 的 virtual function (虚拟 函数 ) 被 调用 。 在 Rectangle::draw 中 ，default 
parameter value (RAB iA) 是 Green。 然 而 ， 因 为 pr 的 static type (静态 类 型 ) 是 
Shape*， 这 个 图 数 调 用 的 default parameter value ( 缺 省 参数 值 ) 是 从 Shape class 中 取得 
的 ， 而 不 是 Rectangle class! 导致 的 结果 就 是 一 个 调用 由 “奇怪 的 和 几乎 完全 出 乎 意料 的 
Shape 和 Rectangle 两 个 classes (类 ) 中 的 draw 声明 的 混合 物 " 所 组 成 。 


ps，pc， 和 pr 是 pointers (指针 ) 的 事实 与 这 个 问题 并 无 因果 关系 ， 如 果 它 们 是 
references (引用 ) ， 问 题 依然 会 存在 。 唯 一 重要 的 事情 是 draw 是 一 个 virtual function (È 
拟 函 数 ) ， 而 它 的 一 个 default parameter values (RBBB) 在 一 个 derived class (派生 
类 ) 中 被 重 定义 。 


为 什么 C++ 要 坚持 按照 这 种 不 正常 的 方式 动作 ? 答案 是 为 了 运行 时 效率 。 如 果 default 
parameter values ( 缺 省 参数 值 ) 是 dynamically bound (动态 绑 定 ) ，compilers (编译 器 ) 
就 必须 提供 一 种 方法 在 运行 时 确定 virtual functions (虚拟 函数 ) 的 parameters (参数 ) 的 
default value(s) 〈 缺 省 值 ) ， 这 比 目 前 在 编译 期 确定 它们 的 机 制 更 慢 而 且 更 复杂 。 最 终 的 决定 
偏向 了 速度 和 实现 的 简单 这 一 边 ， 而 造成 的 结果 就 是 你 现在 可 以 享受 高 效 运行 的 乐趣 ， 但 
是 ， 如 果 你 忘记 留心 本 ltem 的 建议 ， 就 会 陷入 困惑 。 


这 样 就 很 彻底 而 且 完 美 了 ， 但 是 看 看 如 果 你 试图 遵循 本 规则 为 base ( 基 类 ) 和 derived 


classes (派生 类 ) 的 用 户 提供 同样 的 default parameter values ( 缺 省 参数 值 ) HARE 
人: 


class Shape { 
public: 
enum ShapeColor { Red, Green, Blue }; 


virtual void draw(ShapeColor color = Red) const = 0; 


J; 
class Rectangle: public Shape { 
public: 
virtual void draw(ShapeColor color = Red) const; 
J; 


1, code duplication (代码 重复 ) . code duplication (代码 重复 ) #3 dependencies (tk 
HAR) : 如 果 Shape 中 的 default parameter values (WABA) 发 生变 化 ， 所 有 重复 了 
它 的 derived classes (派生 类 ) 必须 同时 变化 。 否 则 它们 就 陷入 重 定义 一 个 inherited default 
parameter value (通过 继承 得 到 的 缺 省 参数 值 ) 。 怎 么 办 呢 ? 


当 你 要 一 个 virtual function (虚拟 函数 ) 按照 你 希望 的 方式 运行 有 困难 的 时 人 息 ， 考 虑 可 选 的 蔡 
代 设 计 是 很 明智 的 ， 而 且 ltem 35 给 出 了 多 个 virtual function (MBM) 的 替代 方法 。 蔡 代 
方法 之 一 是 non-virtual interface idiom (NVI idiom) ( 非 虚拟 接口 惯用 法 ) : 用 base 


class (£2) 中 的 public non-virtual function (公有 非 虚拟 函数 ) 调用 derived classes ( 派 
4) 可 能 重 定义 的 private virtual function (私有 虚拟 函数 ) 。 这 里 ， 我 们 用 non-virtual 
function ( 非 虚拟 函数 ) 指定 default parameter ( 缺 省 参数 ) ， 同 时 使 用 virtual function (Œ 
WR) 做 实际 的 工作 : 

class Shape { 


public: 
enum ShapeColor { Red, Green, Blue }; 


void draw(ShapeColor color = Red) const // now non-virtual 
doDraw(color); // calls a virtual 
} 
private: 
virtual void doDraw(ShapeColor color) const = 0; // the actual work is 
}; // done in this func 


class Rectangle: public Shape { 


public: 
private: 

virtual void doDraw(ShapeColor color) const; // note lack of a 

Sap // default param val. 
J; 


因为 non-virtual functions 〈 非 虚拟 函数 ) 绝 不 应 该 被 derived classes (派生 类 ) 
overridden (im) (参见 Item 36) ， 这 个 设计 使 得 draw 的 color parameter (参数 ) 的 
default value ( 缺 省 值 ) 应 该 永远 是 Red ¥ HAAR. 


Things to Remember 


绝 不 要 重 定义 一 个 inherited default parameter value (通过 继承 得 到 的 缺 省 参数 值 ) ， 因 为 
default parameter value ( 缺 省 参数 值 ) 是 statically bound (静态 绑 定 ) ， 而 virtual functions 
一 一 应 该 是 你 可 以 overriding (im) 的 仅 有 的 函数 一 一 是 dynamically bound (动态 绑 

定 ) 。 


Item 38: 通过 composition (24) 模拟 "has- 
a" (有 一 个 ) 3 "is-implemented-in-terms- 
of" (是 根据 ..….. 实 现 的 ) 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


composition (复合 ) 是 在 objects of one type (一 个 类 型 的 对 象 ) 包含 objects of another 
type ( 另 一 个 类 型 的 对 象 )》 时 ，types (类 型 ) 之 间 的 关系 。 例 如 : 


class Address { ... }; // where someone lives 
class PhoneNumber { ... }; 


class Person { 


public: 

private: 
std::string name; // composed object 
Address address; // ditto 
PhoneNumber voiceNumber; // ditto 
PhoneNumber faxNumber; // ditto 

}; 


此 例 之 中 ，Person objects (对 象 ) 由 string, Address, #1 PhoneNumber objects (对 象 ) 
组 成 。 在 程序 员 中 ， 术 语 composition (2A) 有 很 多 同义词 。 它 也 可 以 称 为 layering, 
containment，aggregation， 和 embedding。 


Item 32 解释 了 public inheritance (公有 继承 ) 意味 着 "is-a" (是 一 个 ) 。composition ( 复 
£) 也 有 一 个 含意 。 实 际 上 ， 他 有 两 个 含意 。composition (24) 既 意 味 着 "has-a" (有 一 
个 ) ， 又 意味 着 "is-implemented-in-terms-of" (是 根据 ...... 实 现 的 ) 。 这 是 因为 你 要 在 你 的 软 
件 中 处 理 两 个 不 同 的 domains (领域 )。 你 程序 中 的 一 些 objects (对 象 ) 对 应 你 所 模拟 的 世 
界 里 的 东西 ， 例 如 ，people (A) , vehicles (交通 工具 ) ，video frames (视频 画面 ) 等 
等 。 这 样 的 objects (对 象 ) Æ application domain (应 用 领域 ) 的 部 分 。 另 外 的 objects (对 
R) 纯粹 是 implementation artifacts (实现 的 产物 ) ， 例 如 ，buffers (缓冲 区 ) , 

mutexes 〈 互 斥 体 ) , search trees (搜索 树 ) 等 等 。 这 些 各 类 objects (对 象 ) 定义 应 你 的 软 
件 的 implementation domain (实现 领域 ) 。 当 composition (复合 ) 发 生 在 application 
domain 〈 应 用 领域 ) BY objects (4R) 之 间 ， 它 表达 一 个 has-a (有 一 个 ) 的 关系 ， 当 它 发 
生 在 implementation domain 〈 实 现 领域 ) ， 它 表达 一 个 is-implemented-in-terms-of (是 根 


据 .…... 实 现 的 ) 的 关系 


上 面 的 Person class (#) 示范 了 has-a (有 一 个 ) 的 关系 。 一 个 Person object (对 象 ) has 
a 《有 一 个 ) 名 字 ， 一 个 地 址 ， 以 及 语音 和 传真 电话 号 码 。 你 不 能 说 一 个 人 is a (是 一 个 ) 名 
字 或 一 个 人 is an (是 一 个 ) 地 址 。 你 可 以 说 一 个 人 hasa (有 一 个 ) 名 字 和 hasan (有 一 
个 ) 地 址 。 大 多 数 人 对 此 区 别 不 难 理解 ， 所 以 混淆 is-a (是 一 个 ) 和 has-a (有 一 个 ) 之 间 的 
角色 的 情况 非常 少见 。 


is-a (是 一 个 ) 和 is-implemented-in-terms-of (是 根据 .……. 实现 的 ) ZANE ama LR 
手 。 例 如 ， 假 设 你 需要 一 个 类 的 模板 来 表现 相当 小 的 objects (对 象 ) 的 sets， 也 就 是 说 ， 排 
除 重复 的 集合 。 因 为 reuse (2A) 是 一 件 受 人 欢迎 的 事情 ， 你 的 第 一 个 直觉 就 是 使 用 标准 库 
中 的 set template (模板 ) 。 当 你 能 使 用 已 经 被 写 好 的 东西 时 ， 为 什么 还 要 写 一 个 新 的 
template (模板 ) We? 


TEHE, set 的 典型 实现 导致 每 个 元 素 三 个 指针 的 开销 。 这 是 因为 sets 通常 被 作为 
balanced search trees (平衡 搜索 树 ) 来 实现 ， 这 人 允许 它们 保证 logarithmic-time (对 数 时 
ï) BY lookups (查找 ) , insertions (插入 ) 和 erasures (WIR) 。 当 速度 比 空间 更 重要 的 
时 候 ， 这 是 一 个 合理 的 设计 ， 但 是 当空 间 比 速度 更 重要 时 ， 对 你 的 程序 来 说 就 有 问题 了 。 
而 ， 对 你 来 说 ， 标 准 库 的 set 为 你 提供 了 不 合理 的 交易 。 看 起 来 你 终究 还 是 要 写 你 自己 的 
template (模板 ) 。 


reuse ( 复 用 ) 依然 是 一 件 受 人 欢迎 的 事情 。 作 为 data structure (数据 结构 ) 的 专家 ， 你 知道 
实现 sets 的 诸多 选择 ， 其 中 一 种 是 使 用 linked lists (线性 链表 ) 。 你 也 知道 标准 的 C++ EA 
有 一 个 list template (模板 ) ， 所 以 你 决定 〈 复 ) Ae. 


具体 地 说 ， 你 决定 让 你 的 新 的 Set template (模板 ) M list 继承 。 也 就 是 说 ，Set<T> 将 从 
list<T> 继承 。 毕竟 ， 在 你 的 实现 中 ， 一 个 Set object (对 象 ) 实际 上 就 是 一 个 list object (xt 
象 ) 。 于 是 ， 你 就 像 这 样 声 明 你 的 Set template (模板 ) 


template<typename T> // the wrong way to use list for Set 
class Set: public std::list<T> { ... }; 


在 这 里 ， 看 起 来 每 件 事情 都 很 好 。 但 实际 上 有 一 个 很 大 的 错误 。 就 像 Item 32 中 的 解释 ， 如 果 


D is-a (是 一 个 ) B， 对 于 B 成 立 的 每 一 件 事情 对 D 也 成 立 。 然 而 ， 一 个 list object (对 象 ) 
可 以 包含 重复 ， 所 以 如 果 值 3051 被 插入 一 个 list<int> 两 次 ， 那 个 list 将 包含 3051 的 两 个 找 
贝 。 与 此 对 照 ， 一 个 Set 不 可 以 包含 重复 ， 所 以 如 果 值 3051 被 插入 一 个 Set<int> AR, FB 


个 set 只 包含 该 值 的 一 个 拷贝 。 因 此 一 个 Set is-a (是 一 个 ) list 是 不 正确 的 ， 因 为 对 list 
objects (对 象 ) 成 立 的 某 些 事情 对 Set objects (对 象 ) 不成立。 


因为 这 两 个 classes (类 ) 之 间 的 关系 不 是 is-a (是 一 个 ) ，public inheritance (公有 继承 ) 
不 是 模拟 这 个 关系 的 正确 方法 。 正 确 的 方法 是 认识 到 一 个 Set object (对 象 ) 可 以 be 
implemented in terms of a list object (是 根据 一 个 list 对 象 实现 的 ) 


template<class T> // the right way to use list for Set 
class Set { 
public: 

bool member(const T& item) const; 


void insert(const T& item); 
void remove(const T& item); 


std::size_t size() const; 


private: 
std::list<T> rep; // representation for Set data 


}; 


Set 的 member functions (A ABA) 可 以 极 大 程度 地 依赖 list 和 标准 库 的 其 它 部 分 已 经 提供 
的 机 能 ， 所 以 只 要 你 熟悉 了 用 STL 编程 的 基本 方法 ， 实 现 就 非常 简单 了 : 


template<typename T> 
bool Set<T>: :member(const T& item) const 


{ 


return std::find(rep.begin(), rep.end(), item) != rep.end(); 


} 


template<typename T> 
void Set<T>::insert(const T& item) 


if (!member(item)) rep.push_back(item); 


} 


template<typename T> 
void Set<T>::remove(const T& item) 


{ 
typename std::list<T>::iterator it = // see Item 42 for info on 
std::find(rep.begin(), rep.end(), item); // "typename" here 
if (it != rep.end()) rep.erase(it); 
} 


template<typename T> 
std::size_t Set<T>::size() const 


{ 


return rep.size(); 


} 


这 些 画 数 足够 简单 ， 使 它们 成 为 inlining (内 联 化 ) 的 合理 候选 者 ， 可 是 我 知道 在 坚定 
inlining (内 联 化 ) 的 决心 之 前 ， 你 可 能 需要 回顾 一 下 Item 30 中 的 讨论 。 


一 个 有 说 服 力 的 观点 是 ， 根 据 ltem 18 的 关于 将 interfaces (接口 ) 设计 得 易于 正确 使 用 ， 而 
难以 错误 使 用 的 论述 ， 如 果 要 遵循 STL container (容器 ) 的 惯例 ，Set 的 interface (接口 ) 

应 该 更 多 ， 但 是 在 这 里 遵循 那些 惯例 就 需要 在 Set 中 填充 大 量 stuff (材料 ) ， 这 将 使 得 它 和 
list 之 间 的 关系 变 得 暧昧 不 清 。 因 为 这 个 关系 是 本 Item 的 重点 ， 我 们 用 教学 的 清晰 性 替换 了 

STL 的 兼容 性 。 除 此 之 外 ，Set 的 interface (接口 ) 的 幼稚 不 应 该 遮掩 关于 Set 的 无 可 争辩 
的 正确 : GA list 之 间 的 关系 。 这 个 关系 不 是 is-a (是 一 个 ) ” (虽然 最 初 看 上 去 可 能 很 像 ) ， 

而 是 is-implemented-in-terms-of (是 根据 .……. 实现 的 ) 。 


Things to Remember 


e composition (复合 ) 与 public inheritance (公有 继承 ) 的 意义 完全 不 同 。 


e JẸ application domain (应 用 领域 ) +, composition (复合 ) 意味 着 has-a (有 一 个 ) 。 
在 implementation domain (实现 领域 ) 中 意味 着 is-implemented-in-terms-of (是 根 
据 ..….... 实 现 的 ) 。 


Item 39: 谨慎 使 用 private inheritance (私有 继 
7K) 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


Item 32 论述 了 C++ 将 public inheritance (公有 继承 ) 视 为 一 个 is-a 关系 。 当 给 定 一 个 
hierarchy (继承 体系 ) ， 其 中 有 一 个 class Student 从 一 个 class Person 公有 继承 ， 当 为 了 
成 功 调用 一 个 函数 而 必需 时 ， 就 要 将 Students 隐 式 转型 为 Persons， 它 通过 向 编译 器 展示 来 
做 到 这 一 点 。 用 private inheritance (私有 继承 ) 代替 public inheritance (公有 继承 ) 把 这 个 
例子 的 一 部 分 重 做 一 下 是 值得 的 : 


class Person { ... }; 

class Student: private Person { ... }; // inheritance is now private 

void eat(const Person& p); // anyone can eat 

void study(const Student& s); // only students study 

Person p; // p is a Person 

Student s; // s is a Student 

eat(p); // fine, p is a Person 

eat(s); // error! a Student isn't a Person 


很 明显 ，private inheritance (私有 继承 ) 不 意味 着 is-a。 那 么 它 意 味 着 什么 呢 ? 


“IR 1” 你 说 : “在 我 们 得 到 它 的 含义 之 前 ， 我 们 先 看 看 它 的 行为 。private inheritance (私有 继 
承 ) 有 怎样 的 行为 呢 ? "好 吧 ， 支 配 private inheritance (私有 继承 ) 的 第 一 个 规则 你 只 能 从 动 
作 中 看 到 : 与 public inheritance (公有 继承 ) 对 照 ， 如 果 classes (类 ) 之 间 的 inheritance 
relationship (继承 关系 ) 是 private (MA) 的 ， 编 译 器 通常 不 会 将 一 个 derived class 
object (派生 类 对 象 ) (诸如 Student) 转型 为 一 个 base class object ( 基 类 对 象 ) (诸如 
Person) 。 这 就 是 为 什么 为 object (对 象 ) s 调用 eat 会 失败 。 第 二 个 规则 是 从 一 个 private 
base class (私有 基 类 ) 继承 的 members (成 员 ) 会 成 为 derived class (派生 类 ) 的 private 
members (私有 成 员 ) ， 即 使 它们 在 base class ( 基 类 ) 中 是 protected (保护 ) 的 或 
public( 公 有) 的。 


行为 不 过 如 此 。 这 就 给 我 们 带 来 了 含义 。private inheritance (私有 继承 ) 意味 着 is- 
implemented-in-terms-of 〈 是 根据 .……: 实 现 的 ) 。 如 果 你 使 class (类 ) D 从 class (#) B 私 
有 继承 ， 你 这 样 做 是 因为 你 对 于 利用 在 class (类 ) B 中 才 可 用 的 某 些 特性 感 兴 趣 ， 而 不 是 因 
AE types (类 型 ) B 和 types (类 型 ) D 的 objects (对 象 ) 之 间 有 什么 概念 上 的 关系 。 同 样 
th, private inheritance (私有 继承 ) 纯粹 是 一 种 实现 技术 。 (这 也 就 是 为 什么 你 从 一 个 


private base class (私有 基 类 ) 继承 的 每 一 件 东 西 都 在 你 的 class (类 ) PEAK private ( 私 
有 ) 的 原因 : 它 全 部 都 是 实现 的 细节 。) 利用 Item 34 中 提出 的 条 款 ，private 

inheritance (私有 继承 ) 意味 着 只 有 implementation (实现 ) 应 该 被 继承 ; interface (接口 ) 
应 该 被 忽略 。 如 果 D 从 B 私有 继承 ， 它 就 意味 着 D objects are implemented in terms of B 
objects (D 对 象 是 根据 B 对 象 实现 的 ) ， 没 有 更 多 了 。private inheritance (私有 继承 ) 在 
software design (软件 设计 ) 期 间 没 有 任何 意义 ， 只 在 software implementation (软件 实 
现 ) 期 间 才 有 。 


private inheritance (私有 继承 ) 意味 着 is-implemented-in-terms-of 〈 是 根据 .…… 实现 的 ) 的 
事实 有 一 点 混乱 ， 因 为 ltem 38 指出 composition (复合 ) 也 有 同样 的 含义 。 你 怎么 预先 在 它 
们 之 间 做 出 选择 呢 ?答案 很 简单 : 只 要 你 能 就 用 composition 〈 复 合 ) ， 只 有 在 绝对 必要 的 时 
候 才 用 private inheritance (私有 继承 ) 。 什 么 时 候 是 绝对 必要 呢 ? 主要 是 当 protected 
members (保护 成 员 ) 和 /或 virtual functions (HEPES) 迭 和 进来 的 时 候 ， 另 外 还 有 一 种 与 
空间 相关 的 极端 情况 会 使 天 平 向 private inheritance (私有 继承 ) 倾斜 。 我 们 稍 后 再 来 操心 这 
种 极端 情况 。 毕竟 ， 它 只 是 一 种 极端 情况 。 


假设 我 们 工作 在 一 个 包含 Widgets 的 应 用 程序 上 ， 而 且 我 们 认为 我 们 需要 更 好 地 理解 
Widgets 是 怎样 被 使 用 的 。 例 如 ， 我 们 不 仅 要 知道 Widget member functions (AK A RRO 被 
调用 的 频 度 ， 还 要 知道 call ratios (调用 率 ) 随 着 时 间 的 流逝 如 何 变化 。 带 有 清晰 的 执行 阶段 
的 程序 在 不 同 的 执行 阶段 可 以 有 不 同 的 行为 侧重 。 例 如 ， 一 个 编译 器 在 解析 阶段 对 函数 的 使 
用 与 优化 和 代码 生成 阶段 就 有 很 大 的 不 同 。 


我 们 决定 修改 Widget class 以 持续 跟踪 每 一 个 member function (KABA) 被 调用 了 多 少 
次 。 在 运行 时 ， 我 们 可 以 周期 性 地 检查 这 一 信息 ， 与 每 一 个 Widget 的 这 个 值 相伴 的 可 能 还 有 
我 们 觉得 有 用 的 其 它 数据 。 为 了 进行 这 项 工作 ， 我 们 需要 设立 某 种 类 型 的 timer (计时 器 ) ， 
以 便 在 到 达 收 集 用 法 统计 的 时 间 时 我 们 可 以 知道 。 


尽 可 能 复 用 已 有 代码 ， 而 不 是 写 新 的 代码 ， 我 在 我 的 工具 包 中 翻 箱 倒 柜 ， 而 且 满 意 地 找到 下 
面 这 个 class (类 ) 


class Timer { 
public: 
explicit Timer(int tickFrequency) ; 
virtual void onTick() const; // automatically called for each tick 


这 正 是 我 们 要 找 的 : 一 个 我 们 能 够 根据 我 们 的 需要 设 定 tick 频率 的 Timer object， 而 在 每 次 
tick 时 ， 它 调用 一 个 virtual function (Ha) 。 我 们 可 以 重 定义 这 个 virtual function (kz 
PHM) 以 便 让 它 检 查 Widget 所 在 的 当前 状态 。 很 完美 ! 


为 了 给 Widget BEX Timer 中 的 一 个 virtual function (虚拟 函数 ) , Widget 必须 从 Timer 继 
承 。 但 是 public inheritance (公有 继承 ) 在 这 种 情况 下 不 合适 。Widget is-a (是 一 个 ) Timer 
不 成 立 。Widget 的 客户 不 应 该 能 够 在 一 个 Widget 上 调用 onTick， 因 为 在 概念 上 那 不 是 的 


Widget 的 interface (接口 ) WBS. iF RHNBABAHES Pp BARAIRA Widget 的 
interface (接口 ) ， 这 是 一 个 对 Item 18 的 关于 “使 接口 易于 正确 使 用 ， 而 难以 错误 使 用 ”的 建 
议 的 明显 违背 。public inheritance (公有 继承 ) 在 这 里 不 是 正确 的 选项 。 


因此 我 们 就 inherit privately (秘密 地 继承 ) 


class Widget: private Timer { 
private: 
virtual void onTick() const; // look at Widget usage data, etc. 


om 


通过 private inheritance (私有 继承 ) 的 能 力 ，Timer 的 public (公有 ) onTick RATE Widget 
He mx private (私有 ) 的 ， 而 且 在 我 们 重新 声明 它 的 时 候 ， 也 把 它 保留 在 那里 。 重 复 一 次 ， 
将 onTick 放 入 public interface (公有 接口 ) 将 误导 客户 认为 他 们 可 以 调用 它 ， 而 这 违背 了 
Item 18。 


这 是 一 个 很 好 的 设计 ， 但 值得 一 提 的 是 ，private inheritance (私有 继承 ) 并 不 是 绝对 必要 
的 。 如 果 我 们 决定 用 composition (复合 ) 来 代替 ， 也 是 可 以 的 。 我 们 久 需 要 在 我 们 从 Timer 
公有 继承 来 的 Widget 内 声明 一 个 private nested class (AERE X) ， 在 那里 重 定义 
onTick， 并 在 Widget 中 放置 一 个 那个 类 型 的 object (对 象 ) 。 以 下 就 是 这 个 方法 的 概要 : 


class Widget { 
private: 
class WidgetTimer: public Timer { 
public: 
virtual void onTick() const; 


WidgetTimer timer; 





这 个 设计 比 只 用 了 private inheritance (私有 继承 ) 的 那 一 个 更 复杂 ， 因 为 它 包 括 (public) 
inheritance ( (24:4) 继承 ) 和 composition (复合 ) 两 者 ， 以 及 一 个 新 class (WidgetTimer) 
的 引入 。 老 实说 ， 我 出 示 它 主要 是 为 了 提醒 你 有 多 于 一 条 的 道路 通 向 一 个 设计 问题 ， 而 且 它 
对 于 考虑 多 种 方法 的 自我 训练 也 有 相当 的 价值 (参见 ltem 35) 。 然 而 ， 我 可 以 想到 为 什么 你 
可 能 更 愿意 用 public inheritance (公有 继承 ) 加 composition (复合 ) 而 不 用 private 
inheritance (私有 继承 ) 的 两 个 原因 。 


首先 ， 你 可 能 要 做 出 允许 Widget 有 derived classes (派生 类 ) 的 设计 ， 但 是 你 还 可 能 要 禁止 
derived classes (派生 类 ) 重 定义 onTick。 如 果 Widget 从 Timer 继承 ， 那 是 不 可 能 的 ， 即 使 
inheritance (继承 ) 是 private 〈 私 有 ) 的 也 不 行 。 (回忆 Item 35 derived classes (派生 
类 ) 可 以 重 定义 virtual functions (虚拟 图 数 ) ， 即 使 调用 它们 是 不 被 允许 的 。) 但 是 如 果 
WidgetTimer 在 Widget 中 是 private (私有 ) 的 而 且 是 从 Timer 继承 的 ，Widget 的 derived 
classes (派生 类 ) 就 不 能 访问 WidgetTimer， 因 此 就 不 能 从 它 继承 或 重 定义 它 的 virtual 
functions (zp) 。 如 果 你 会 在 Java 或 CH 中 编程 并 且 错 过 了 禁止 derived classes (ik 
生 类 ) 重 定 义 virtual functions (虚拟 函数 ) 的 能 力 (也 就 是 ，Java 的 final methods (方法 ) 
和 C# 的 sealed) ， 现 在 你 有 了 一 个 在 C++ 中 的 到 类 似 行为 的 想法 。 


第 二 ， 你 可 能 需要 最 小 化 Widget 的 compilation dependencies (编译 依赖 ) 。 如 果 Widget 
从 Timer 继承 ， 在 Widget 被 编译 的 时 候 Timer 的 definition (定义 ) 必须 是 可 用 的 ， 所 以 定 
SL Widget 的 文件 可 能 不 得 不 #include Timer.h, 另 一 方面 ， 如 果 WidgetTimer 移出 Widget 
而 Widget 只 包含 一 个 指向 一 个 WidgetTimer 的 pointer (指针 ) ，Widget 就 可 以 只 需 
WidgetTimer class (类 ) 的 一 个 简单 的 declaration (声明 ) ; 为 了 使 用 Timer 它 不 需要 
#include 任何 东西 。 对 于 大 型 系统 ， 这 样 的 隔离 可 能 非常 重要 (关于 minimizing compilation 
dependencies (最 小 化 编译 依赖 ) 的 细节 ， 参 见 ltem 31) 。 


我 早 些 时 候 谈 及 private inheritance (私有 继承 ) 主要 用 武之 地 是 当 一 个 将 要 成 为 derived 
class (派生 类 ) 的 类 需要 访问 将 要 成 为 base class ( 基 类 ) 的 类 的 protected parts (保护 构 
件 ) ， 或 者 希望 重 定义 一 个 或 多 个 它 的 virtual functions (虚拟 函数 ) ， 但 是 classes (类 ) 之 
间 的 概念 上 的 关系 却 是 is-implemented-in-terms-of， 而 不 是 is-a。 然 而 ， 我 也 说 过 有 一 种 涉 
及 space optimization (空间 最 优化 ) 的 极端 情况 可 能 会 使 你 倾向 于 private inheritance ( 私 
有 继承 ) ， 而 不 是 composition (2A) 。 


这 个 极端 情况 确实 非常 尖锐 : 它 仅 仅 适用 于 你 处 理 一 个 其 中 没有 数据 的 class (类 ) 的 时 候 。 
这 样 的 classes (类 ) 没有 non-static data members ( 非 静 态 数据 成 员 ) ; 没有 virtual 
functions (HBR) (因为 存在 这 样 的 函数 会 在 每 一 个 object (对 象 ) 中 增加 一 个 vptr 一 一 
参见 ltem 7) ; 也 没有 virtual base classes (虚拟 基 类 ) (因为 这 样 的 base classes ( 基 
类 ) 也 会 引起 size overhead (大 小 成 本 ) 参见 ltem 40) 。 在 理论 上 ， 这 样 的 empty 
classes ( 空 类 ) 的 objects (对 象 ) 应 该 不 占用 空间 ， 因 为 没有 per-object ( 逐 对 象 ) 的 数据 
需要 存储 。 然 而 ， 由 于 C++ 天 生 的 技术 上 的 原因 ，freestanding objects (独立 对 象 ) 必须 有 
non-zero size ( 非 需 大 小 ) ， 所 以 如 果 你 这 样 做 ， 





class Empty {}; // has no data, so objects should 
// use no memory 
class HoldsAnInt { // should need only space for an int 
private: 
int x; 


Empty e; // should require no memory 


你 将 发 现 sizeof(HoldsAnInt) > sizeof(int) ; 一 个 Empty data member ( 空 数据 成 员 ) BE 
储 。 对 以 大 多 数 编译 器 ，sizeof(Empty) 是 1， 这 是 因为 C++ 法 则 反对 zero-size 的 
freestanding objects (独立 对 象 ) 一 般 是 通过 在 "empty" objects 〈“ 空 "对 象 ) 中 插入 一 个 
char 完成 的 。 然 而 ，alignment requirements (对 齐 需求 ) (参见 Item 50) 可 能 促使 编译 器 
向 类 似 HoldsAnlnt 的 classes (类 ) 中 增加 填充 物 ， 所 以 ， 很 可 能 HoldsAnlnt objects 得 到 
的 不 仅仅 是 一 个 char 的 大 小 ， 实 际 上 它们 可 能 会 扩张 到 足以 占据 第 二 个 int 的 位 置 。 (在 我 
测试 过 的 所 有 编译 器 上 ， 这 毫 无 例外 地 发 生 了 。) 


但 是 也 许 你 已 经 注意 到 我 小 心 翼 如 地 说 "freestanding" objects (“独立 对象) 必然 不 会 有 zero 
size。 这 个 约束 不 适用 于 base class parts of derived class objects (派生 类 对 象 的 基 类 构 

件 ) ， 因 为 它们 不 是 独立 的 。 如 果 你 用 从 Empty 继承 代替 包含 一 个 此 类 型 的 object (对 
R), 


class HoldsAnInt: private Empty { 
private: 
int x; 


}; 


你 几乎 总 是 会 发 现 sizeof(HoldsAnlnt) == sizeof(int)。 这 个 东西 以 empty base optimization 
(EBO) ( 空 基 优化 ) 闻名 ， 而 且 它 已 经 被 我 测试 过 的 所 有 编译 器 实现 。 如 果 你 是 一 个 空间 敏感 
的 客户 的 库 开 发 者 ，EBO 就 值得 了 解 。 同 桩 值得 了 解 的 是 EBO 通常 只 在 single 

inheritance ( 单 继承 ) 下 才 可 行 。 支 配 C++ object layout (C++ 对 象 布局 ) 的 规则 通常 意味 
着 EBO 不 适用 于 拥有 多 于 一 个 base ( 基 ) 的 derived classes (派生 类 ) 。 


在 实践 中 ，"empty" classes (“ 空 "类 ) 并 不 真 的 为 空 。 虽 然 他 们 绝对 不 会 有 non-static data 
members (〈 非 静态 数据 成 员 ) ， 但 它们 经 常会 包含 typedefs，enums ( 枚 举 ) , static data 
members (静态 数据 成 员 ) ， 或 non-virtual functions ( 非 虚 拟 函 数 ) 。STL 有 很 多 包含 有 用 
的 members (成 员 ) (通常 是 typedefs) 的 专门 的 empty classes (22%) ， 包 括 base 
classes (4£#) unary_function 和 binary_function, user-defined function objects (FA > Œ 
义 函 数 对 象 ) 通常 从 这 些 classes (类 ) 继承 而 来 。 感 谢 EBO 的 普通 实现 ， 这 样 的 继承 很 少 
增加 inheriting classes (继承 来 的 类 ) 的 大 小 。 


尽管 如 此 ， 我 们 还 是 要 回 为 基础 。 大 多 数 classes (类 ) 不 是 空 的 ， 所 以 EBO 很 少 会 成 为 
private inheritance (私有 继承 ) 的 一 个 合理 的 理由 。 此 外 ， 大 多 数 inheritance (继承 ) 相当 
于 is-a， 而 这 正 是 public inheritance (公有 继承 ) 而 非 private (私有 ) 所 做 的 事 。 
composition (复合 ) 和 private inheritance (私有 继承 ) 两 者 都 意味 着 is-implemented-in- 
terms-of (是 根据 .……. 实现 的 ) ， 但 是 composition (2A) 更 易于 理解 ， 所 以 你 应 该 尽 你 所 
能 使 用 它 。 


private inheritance (私有 继承 ) 更 可 能 在 以 下 情况 中 成 为 一 种 设计 策略 ， 当 你 要 人 处理 的 两 个 
classes (类 ) 不 具有 is-a (是 一 个 ) 的 关系 ， 而 且 其 中 的 一 个 还 需要 访问 另 一 个 的 protected 
members ( 保 扩 成 员 ) 或 需要 重 定义 一 个 或 更 多 个 它 的 virtual functions (mem) 。 其 至 
在 这 种 情况 下 ， 我 们 也 看 到 public inheritance 和 containment 的 混合 使 用 通常 也 能 产生 你 想 


BATA, BABRAWE SE. lR private inheritance (私有 继承 ) 意味 着 在 使 
用 它 的 时 候 ， 已 经 考虑 过 所 有 的 可 选 方案 ， 只 有 它 才 是 你 的 软件 中 明确 表示 两 个 
classes 〈 类 ) 之 间 关 系 的 最 佳 方法 。 


Things to Remember 


e private inheritance (私有 继承 ) 意味 着 is-implemented-in-terms of (是 根据 ..…... 实 现 
BY) 。 它 通常 比 composition (复合 ) 更 低级 ， 但 当 一 个 derived class (REX) 需要 访 
问 protected base class members ( 保 折 基 类 成 员 ) 或 需要 重 定义 inherited virtual 
functions 〈 继 承 来 的 虚拟 函数 ) 时 它 就 是 合理 的 。 


。 与 composition (复合 ) 不 同 ，private inheritance (私有 继承 ) 能 使 empty base 
optimization ( 空 基 优 化 ) 有 效 。 这 对 于 致力 于 最 小 化 object sizes (对 象 大 小 ) 的 库 开 发 
者 来 说 可 能 是 很 重要 的 。 


Item 40: 谨慎 使 用 multiple inheritance (4 4% 
7K ) 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


触及 multiple inheritance (MI) (多 继承 ) 的 时 候 ，C++ 社区 就 会 鲜明 地 分 裂 为 两 个 基本 的 阵 
营 。 一 个 阵营 认为 如 果 single inheritance (SI) ( 单 继承 ) 是 有 好 处 的 ，muiltiple 

inheritance (多 继承 ) 一 定 更 有 好 处 。 另 一 个 阵营 认为 single inheritance ( 单 继承 ) 有 好 
处 ， 但 是 多 继承 引起 的 麻烦 使 它 得 不 偿 失 。 在 这 个 ltem 中 ， 我 们 的 主要 目的 是 理解 在 MI 问 
题 上 的 这 两 种 看 法 。 


首要 的 事情 之 一 是 要 承认 当 将 MI 引入 设计 领域 时 ， 就 有 可 能 从 多 于 一 个 的 base class ( 基 
类 ) 中 继承 相同 的 名 字 (例如 ， 画 数 ，typedef， 等 等 ) 。 这 就 为 歧义 性 提供 了 新 的 时 机 。 例 
如 : 


class BorrowableItem { // something a library lets you borrow 
public: 

void checkOut(); // check the item out from the library 
}; 
class ElectronicGadget { 
private: 

bool checkOut() const; // perform self-test, return whether 


// test succeeds 


}; 

class MP3Player: // note MI here 
public BorrowableItem, // (some libraries loan MP3 players) 
public ElectronicGadget 

ne // class definition is unimportant 


MP3Player mp; 


mp.checkOut(); // ambiguous! which checkOut? 


注意 这 个 例子 ， 即 使 两 个 函数 中 只 有 一 个 是 可 访问 的 ， 对 checkOut 的 调用 也 是 有 歧义 的 。 

(checkOut 在 Borrowableltem 中 是 public (公有 ) 的 ， 但 在 ElectronicGadget 中 是 
private (私有 ) 的 。) 这 与 C++ 解析 overloaded functions (BRAM) 调用 的 规则 是 一 致 
的 : 在 看 到 一 个 函数 的 是 否 可 访问 之 前 ，C++ 首先 确定 与 调用 匹配 最 好 的 那个 画 数 。 只 有 在 
确定 了 best-match function (最 佳 匹 配 琅 数 ) 之 后 ， 才 检查 可 访问 性 。 这 目前 的 情况 下 ， 两 
个 checkOuts 具有 相同 的 匹配 程度 ， 所 以 就 不 存在 最 佳 匹 配 。 因 此 永远 也 不 会 检查 到 
ElectronicGadget::checkOut 的 可 访问 性 。 


为 了 消除 歧义 性 ， 你 必须 指定 哪 一 个 base class ( 基 类 ) WRA AHA : 


mp.BorrowableItem: :checkOut(); // ah, that checkOut... 


当然 ， 你 也 可 以 尝试 显 式 调用 ElectronicGadget::checkOut， 但 这 样 做 会 有 一 个 "you're trying 
to call a private member function" (你 试图 调用 一 个 私有 成 员 函 数 ) 错误 代替 歧义 性 错误 。 


multiple inheritance (多 继承 ) 仅仅 意味 着 从 多 于 一 个 的 base class (HX) 继承 ， 但 是 在 还 
有 higher-level base classes (更 高 层次 基 类 ) 的 hierarchies (继承 体系 ) 中 出 现 MI 也 并 不 
罕见 。 这 会 导致 有 时 被 称 为 "deadly MI diamond" (致命 的 多 继承 萎 形 ) HER. 


class File { ... }; 
class InputFile: public File { ... }; 
class OutputFile: public File { ... }; 
class IOFile: public InputFile, 

public OutputFile 






InputFile | 


你 拥有 一 个 “在 一 个 base class ( 基 类 ) 和 一 个 derived class (派生 类 ) 之 间 有 多 于 一 条 路 径 
的 inheritance hierarchy (继承 体系 ) ”( 就 像 上 面 在 File 和 IOFile 之 间 ， 有 通过 InputFile 和 
OutputFile 的 两 条 路 径 ) 的 任何 时 候 ， 你 都 必须 面 对 是 否 需要 为 每 一 条 路 径 复制 base 

class 〈 基 类 ) 中 的 data members (数据 成 员 ) 的 问题 。 例 如 ， 假 设 File class 有 一 个 data 
members (数据 成 员 ) fileName, IOFile 中 应 该 有 这 个 field (字段 ) 的 多少 个 拷贝 呢 ?一方 
面 ， 它 从 它 的 每 一 个 base classes ( 基 类 ) 继承 一 个 拷贝 ， 这 就 暗示 IOFile 应 该 有 两 个 
fileName data members (数据 成 员 ) 。 另 一 方面 ， 简 单 的 逻辑 告诉 我 们 一 个 IOFile 

object (对 象 ) 应 该 仅 有 一 个 file name (文件 名 ) ， 所 以 通过 它 的 两 个 base classes ( 基 
类 ) 继承 来 的 fileName field (FE) 不 应 该 被 复制 。 


C++ 在 这 个 争议 上 没有 自己 的 立场 。 它 恰当 地 支持 两 种 选项 ， 虽 然 它 的 缺 省 方式 是 执行 
制 。 如 果 那 不 是 你 想 要 的 ， 你 必须 让 这 个 class (类 ) 带 有 一 个 virtual base class (虚拟 基 
类 ) 的 数据 (也 就 是 File) 。 为 了 做 到 这 一 点 ， 你 要 让 从 它 直 接 继 承 的 所 有 的 classes (类 ) 
使 用 virtual inheritance (虚拟 继承 ) 


class File { ... }; 
class InputFile: virtual public File { ... }; 
class OutputFile: virtual public File { ... }; 


class IOFile: public InputFile, 
public OutputFile 
{ ... }; 


File | 


| InputFile | | OutputFile 


av J 


标准 C++ 库 包 合 一 个 和 此 类 似 的 MI hierarchy (继承 体系 ) ， 只 是 那个 classes (类 ) 是 
class templates (类 模板 ) ， 名 字 是 basic_ios, basic_istream, basic_ostream 和 
basic_iostream， 而 不 是 File，InputFile，OutputFile 和 IOFile。 





从 正确 行为 的 观点 看 ，public inheritance (公有 继承 ) 应 该 总 是 virtual (虚拟 ) 的 。 如 果 这 是 
唯一 的 观点 ， 规 则 就 变 得 简单 了 : 你 使 用 public inheritance (公有 继承 ) 的 任何 时 候 ， 都 使 

FA virtual public inheritance (虚拟 公有 继承 ) 。 唉 ， 正 确 性 不 是 唯一 的 视角 。 避 免 inherited 

fields 〈 继 承 来 的 字段 ) 复制 需要 在 编译 器 的 一 部 分 做 一 些 behind-the-scenes 

legerdemain (幕后 的 戏法 ) ， 而 结果 是 从 使 用 virtual inheritance (虚拟 继承 ) 的 

classes (类 ) 创建 的 objects (对 象 ) 通常 比 不 使 用 virtual inheritance (虚拟 继承 ) HEX, 
访问 virtual base classes (虚拟 基 类 ) 中 的 data members (数据 成 员 ) 也 上 比 那些 non-virtual 
base classes ( 非 虚拟 基 类 ) 中 的 要 慢 。 编 译 器 与 编译 器 之 间 有 一 些 细节 不 同 ， 但 基本 的 要 点 
很 清楚 : virtual inheritance costs (虚拟 继承 要 付出 成 本 ) 。 


它 也 有 一 些 其 它 方面 的 成 本 。 支 配 initialization of virtual base classes (虚拟 基 类 初始 化 ) 的 
规则 比 non-virtual bases 〈 非 虚拟 基 类 ) 的 更 加 复杂 而 且 更 不 直观 。 初 始 化 一 个 virtual 
base (虚拟 基 ) 的 职责 由 hierarchy (继承 体系 ) 中 most derived class 〈 层 次 最 低 的 派生 

类 ) 承担 。 这 个 规则 中 包括 的 含义 : (1) 从 需要 initialization (初始 化 ) 的 virtual 

bases (虚拟 基 ) 派生 的 classes (类 ) 必须 知道 它们 的 virtual bases (虚拟 基 ) ， 无 论 它 距 
BAB bases ( 基 ) 有 多 远 ; (2) 当 一 个 新 的 derived class (派生 类 ) 被 加 入 继承 体系 时 ， 
它 必须 为 它 的 virtual bases (虚拟 基 ) (包括 直接 的 和 间接 的 ) 承担 initialization 
responsibilities (初始 化 职责 ) 。 


我 对 于 virtual base classes (虚拟 基 类 ) (也 就 是 virtual inheritance (虚拟 继承 ) ) 的 建议 
很 简单 。 首 先 ， 除 非 必需 ， 否 则 不 要 使 用 virtual bases (虚拟 基 ) 。 缺 省 情况 下 ， 使 用 non- 
virtual inheritance (〈 非 虚拟 继承 ) 。 第 二 ， 如 果 你 必须 使 用 virtual base classes (虚拟 基 
类 ) ， 试 着 避免 在 其 中 放置 数据 。 这 样 你 就 不 必 在 意 它 的 initialization (初始 化 ) (以 及 它 的 
turns out (清空 ) , assignment (赋值 ) ) 规则 中 的 一 些 怪癖 。 值 得 一 提 的 是 Java 和 .NET 
中 的 Interfaces GEO) 不 允许 包含 任何 数据 ， 它 们 在 很 多 方面 可 以 和 C++ 中 的 virtual base 
classes (虚拟 基 类 ) 相 比 照 。 


现在 我 们 使 用 下 面 的 C++ Interface class (接口 类 ) (参见 Item 31) 来 为 persons (A) 建 
模 : 


class IPerson { 
public: 
virtual ~IPerson(); 


virtual std::string name() const = 0; 
virtual std::string birthDate() const = 0; 


}; 


IPerson 的 客户 只 能 使 用 IPerson 的 pointers (指针 ) 和 references (引用 ) 进行 编程 ， 因 为 
abstract classes (抽象 类 ) 不 能 被 实例 化 。 为 了 创建 能 被 当 作 IPerson objects (对 象 ) 使 用 
的 objects (对 象 ) ，IPerson 的 客户 使 用 factory functions (LT HWA) (再 次 参见 Item 
31) instantiate (实例 化 ) M IPerson 派生 的 concrete classes (具体 类 ) 


// factory function to create a Person object from a unique database ID; 
// see Item 18 for why the return type isn't a raw pointer 
std::tri::shared_ptr<IPerson> makePerson(DatabaseID personIdentifier ); 


// function to get a database ID from the user 
DatabaseID askUserForDatabaseID(); 


DatabaseID id(askUserForDatabaseID()); 

std::tri::shared_ptr<IPerson> pp(makePerson(id)); // create an object 
// supporting the 
// IPerson interface 


// manipulate *pp via 
// IPerson's member 
// functions 


但 是 makePerson 怎样 创建 它 返回 的 pointers (指针 ) 所 指向 的 objects (对 象 ) WE? 显然 ， 
必须 有 一 些 makePerson 可 以 实例 化 的 从 IPerson 派生 的 concrete class (具体 类 ) 。 


假设 这 个 class (类 ) 叫做 CPerson。 作 为 一 个 concrete class (具体 类 ) , CPerson 必须 提 
供 它 从 IPerson 继承 来 的 pure virtual functions ( 纯 虚 拟 画 数 ) 的 implementations ( 实 

m) 。 它 可 以 从 头 开 始 写 ， 但 利用 包含 大 多 数 或 全 部 必需 品 的 现 有 组 件 更 好 一 些 。 例 如 ， 假 
设 一 个 老式 的 database-specific class (老式 的 数据 库 专 用 类 ) Personinfo 提供 了 CPerson 
所 需要 的 基本 要 素 : 


class PersonInfo { 

public: 
explicit PersonInfo(DatabaseID pid); 
virtual ~PersonInfo(); 


virtual const char * theName() const; 
virtual const char * theBirthDate() const; 


private: 
virtual const char * valueDelimOpen() const; // see 
virtual const char * valueDelimClose() const; // below 


fo 


你 可 以 看 出 这 是 一 个 老式 的 class (类 ) ， 因 为 member functions (AK A EX) 返回 const 
char*s 而 不 是 string objects (对 象 )。 尽 管 如 此 ， 如 果 鞋 子 合 适 ， 为 什么 不 穿 呢 ?这 个 
class (类 ) BY member functions (AK APSR) 的 名 字 暗 示 结 果 很 可 能 会 非常 合适 。 


你 突然 发 现 Personinfo Ea R database fields (数据 库 字段 ) 
的 ， 每 一 个 字段 的 值 的 开始 和 结 过 指定 的 字符 串 定 界 。 缺 省 情况 下 ， 字 段 值 开始 和 结尾 
定 界 符 是 方 括号 ， 所 以 字段 值 stant Lemur" 很 可 能 被 安排 成 这 种 格式 : 


[Ring-tailed Lemur] 


根据 方 括号 并 非 满 足 Personlnfo 的 全 体 客户 的 期 望 的 事实 ，virtual functions (i +E RX) 
valueDelimOpen 和 valueDelimClose 允许 derived classes (派生 类 ) 指定 它们 自己 的 开始 和 
结尾 定 界 字符 串 。Personlnfo 的 member functions (AK A EZ) 的 implementations (实现 ) 
调用 这 些 virtual functions (PWR) 在 它们 返回 的 值 上 加 上 适当 的 定 界 符 。 作 为 一 个 例子 
使 用 Personlnfo::theName， 代 码 如 下 : 


const char * PersonInfo::valueDelimOpen() const 


{ 

return "["; // default opening delimiter 
} 
const char * PersonInfo::valueDelimClose() const 

return "]"; // default closing delimiter 
} 
const char * PersonInfo::theName() const 
{ 


// reserve buffer for return value; because this is 
// static, it's automatically initialized to all zeros 
static char value[Max_Formatted_Field_Value_Length]; 


// write opening delimiter 
std::strcpy(value, valueDelimOpen()); 


append to the string in value this object's name field (being careful 
to avoid buffer overruns! ) 


// write closing delimiter 
std::strceat(value, valueDelimClose()); 


return value; 


有 人 可 能 会 质疑 Personinfo::theName 的 陈旧 的 设计 (特别 是 一 个 fixed-size static buffer (E 
定 大 小 静态 组 的 使 用 ， 这 样 的 东西 发 生 overrun (越界 ) A threading (线程 ) 问题 是 
比较 普通 见 ltem 21) ， 但 是 请 把 这 样 的 问题 放 到 一 边 而 注意 这 里 : theName 调用 
valueDelimOpen 生成 它 要 返回 的 string (FFE) 的 开始 定 界 符 ， 然 后 它 生 成 名 字 值 本 身 ， 
然后 它 调 用 valueDelimClose。 





因为 valueDelimOpen 和 valueDelimClose Æ virtual functions (虚拟 函数 ) ，theName 返回 
的 结果 不 仅 依赖 于 Personlnfo， 也 依赖 于 从 Personlnfo 派生 的 classes (类 ) 。 


对 于 CPerson 的 实现 者 ， 这 是 好 消息 ， 因 为 当 细 读 IPerson documentation (X44) 中 的 fine 
print (ERAIK) 时 ， 你 发 现 name 和 birthDate 需要 返回 未 经 修饰 的 值 ， 也 就 是 ， 不 允许 
有 定 界 符 。 换 名 话说 ， 如 果 一 个 人 的 名 字 叫 Homer， 对 那个 人 的 name 函数 的 一 次 调用 应 该 
返回 "Homer"， 而 不 是 "[Homer]"。 


CPerson 和 Personlnfo 之 间 的 关系 是 Personlnfo 碰巧 有 一 些 隙 数 使 得 CPerson 更 容易 实 
现 。 这 就 是 全 部 。 因 而 它们 的 关系 就 是 is-implemented-in-terms-of， 而 我 们 知道 有 两 种 方法 
可 以 表现 这 一 点 : 经 由 composition (复合 ) (参见 Item 38) 和 经 由 private inheritance ( 私 
有 继承 ) (参见 ltem 39) . Item 39 指出 composition (复合 ) 是 通常 的 首选 方法 ， 但 如 果 
virtual functions (虚拟 函数 ) 要 被 重 定义 ，inheritance (继承 ) 就 是 必 不 可 少 的 。 在 当前 情况 
F, CPerson 需要 重 定义 valueDelimOpen 和 valueDelimClose， 所 以 简单 的 

composition (24) 做 不 到 。 最 直截了当 的 解决 方案 是 让 CPerson M Personlnfo privately 
inherit (私有 继承 ) ， 虽 然 ltem 39 说 过 只 要 多 做 一 点 工作 ， 则 CPerson 也 能 

composition (复合 ) 和 inheritance (继承 ) 的 组 合 有 效 地 重 定义 Personinfo 的 virtuals ( 虚 
PSE) 。 这 里 ， 我 们 用 private inheritance (私有 继承 ) 。 


但 是 CPerson 还 必须 实现 IPerson interface (接口 ) ， 而 这 被 称 为 public inheritance (公有 
继承 ) 。 这 就 引出 一 个 multiple inheritance (多 继承 ) 的 合理 应 用 : 组 合 public inheritance 
of an interface (一 个 接口 的 公有 继承 ) 和 private inheritance of an implementation (一 个 实 


现 的 私有 继承 ) 


class IPerson { 
public: 


this class specifies the 
interface to be implemented 


virtual ~IPerson(); 


virtual std::string name() const 0; 


virtual std::string birthDate() const = 0; 
J; 
class DatabaseID { ... }; // used below; details are 
// unimportant 
class PersonInfo { // this class has functions 
public: // useful in implementing 
explicit PersonInfo(DatabaseID pid); // the IPerson interface 


virtual ~PersonInfo(); 
virtual const char * theName() const; 
virtual const char * theBirthDate() const; 
virtual const char * valueDelimOpen() const; 
virtual const char * valueDelimClose() const; 
J; 
class CPerson: public IPerson, private PersonInfo { // note use of MI 
public: 
explicit CPerson( DatabaseID pid): PersonInfo(pid) {} 
virtual std::string name() const // implementations 
{ return PersonInfo::theName(); } // of the required 


// IPerson member 
virtual std::string birthDate() const // functions 
{ return PersonInfo::theBirthDate(); } 
private: // vedefinitions of 


// 
// 


inherited virtual 
delimiter 


const char * valueDelimOpen() const { return ""; } 
const char * valueDelimClose() const { return ""; } 


ten 


在 UML 中 ， 这 个 设计 看 起 来 像 这样 : 


IPerson Personinfo 


下 下 {private} 





CPerson 


这 个 例子 证 明 MI 既是 有 用 的 ， 也 是 可 理解 的 。 


时 至 今日 ，multiple inheritance (多 继承 ) 不 过 是 object-oriented toolbox (面向 对 象 工具 
箱 ) 里 的 又 一 种 工具 而 已 ， 典 型 情况 下 ， 它 的 使 用 和 理解 更 加 复杂 ， 所 以 如 果 你 得 到 一 个 或 
多 或 少 等 同 于 一 个 MI 设计 的 SI 设计 ， 则 SI 设计 总 是 更 加 可 取 。 如 果 你 能 拿 出 来 的 仅 有 的 设 
计 包 含 Ml， 你 应 该 更 加 用 心地 考虑 一 下 一 一 总 会 有 一 些 方 法 使 得 SI 也 能 做 到 。 但 同时 ，MI 
有 时 是 最 清晰 的 ， 最 易于 维护 的 ， 最 合理 的 完成 工作 的 方法 。 在 这 种 情况 下 ， 毫 不 旱 惧 地 使 
用 它 。 只 是 要 确保 谨慎 地 使 用 它 。 


Things to Remember 


mc 


e multiple inheritance (多 继承 ) 比 single inheritance ( 单 继承 ) 更 复杂 。 它 能 


义 问 题 和 对 virtual inheritance (虚拟 继承 ) 的 需要 。 


导致 新 的 歧 


e virtual inheritance (虚拟 继承 ) 增加 了 size (大 小 ) 和 speed (速度 ) 成 本 ， 以 及 
initialization (初始 化 ) 和 assignment (赋值 ) WS *E. 4 virtual base classes (虚拟 
基 类 ) 没有 数据 时 它 是 最 适用 的 。 


e multiple inheritance (多 继承 ) 有 合理 的 用 途 。 一 种 方案 涉及 组 合 从 一 个 Interface 
class (接口 类 ) 的 public inheritance (公有 继承 ) 和 从 一 个 有 助 于 实现 的 class (类 ) 的 
private inheritance (私有 继承 ) 。 


Item 41: 理解 implicit interfaces ( 隐 式 接口 ) 和 
compile-time polymorphism (编译 期 多 态 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


object-oriented programming (面向 对 象 编程 ) 的 世界 是 围绕 着 explicit interfaces ( 显 式 接 
口 ) 和 runtime polymorphism (执行 期 多 态 ) 为 中 心 的 。 例 如 ， 给 出 下 面 这 个 (没有 什么 意 
SLAY) class (#) , 


class Widget { 
public: 
Widget(); 
virtual ~Wwidget(); 
virtual std::size_t size() const; 
virtual void normalize(); 
void swap(Widget& other); // see Item 25 


以 及 这 个 (同样 没有 什么 意义 的 ) function (ERX) , 


void doProcessing(Widget& w) 


if (w.size() > 10 && w != someNastyWidget) { 
Widget temp(w); 
temp.normalize(); 
temp.swap(w); 
} 
} 


我 们 可 以 这 样 谈论 doProcessing 中 的 w: 


。 因为 w 被 声明 为 Widget 类 型 的 引用 ，w 必须 支持 Widget interface (接口 ) 。 我 们 可 以 
在 源 代码 中 找到 这 个 interface (接口 ) (例如 ，Widget 的 .h 文件 ) 以 看 清楚 它 是 什么 样 
子 的 ， 所 以 我 们 称 其 为 一 个 explicit interface ( 显 式 接口 ) 一 一 它 在 源 代码 中 显 式 可 见 。 


。 因为 Widget 的 一 些 member functions (PX A A) 是 虚拟 的 ，w 对 这 些 函 数 的 调用 就 表 
ILA runtime polymorphism (执行 期 多 态 ) : 被 调用 的 特定 男 数 在 执行 期 基于 w 的 
dynamic type (动态 类 型 ) 来 确定 (参见 Item 37) 。 


templates (模板 ) 和 generic programming ( 泛 型 编程 ) 的 世界 是 根本 不 同 的 。 在 那个 世 
界 ，explicit interfaces ( 显 式 接口 ) 和 runtime polymorphism (执行 期 多 态 ) 继续 存在 ， 但 是 
它们 不 那么 重要 了 。 作 为 替代 ， 把 implicit interfaces ( 隐 式 接口 ) 和 compile-time 


polymorphism (编译 期 多 态 ) 推 到 了 前 面 。 为 了 了 解 这 是 怎样 一 种 情况 ， 看 一 下 当 我 们 把 
doProcessing 从 一 个 function (HZ) 转 为 一 个 function template (HARIR) 时 会 发 生 什 
A : 
template<typename T> 
void doProcessing(T& w) 
if (w.size() > 10 && w != someNastyWidget) { 
T temp(w); 


temp.normalize(); 
temp.swap(w); 


现在 我 们 可 以 如 何 谈论 doProcessing 中 的 w 呢 ? 


e w 必须 支持 的 interface (接口 ) 是 通过 template (模板 ) 中 在 w 身上 所 执行 的 操作 确定 
的 。 在 本 例 中 ， 它 显现 为 w 的 type (T) 必须 支持 size, normalize 和 swap member 
functions (AK AEF) ; copy construction ( 找 贝 构造 函数 ) (用 于 创建 temp) ; 以 及 
对 不 等 于 的 比较 (用 于 和 someNastyWidget 之 间 的 比较 ) 。 我 们 将 在 以 后 看 到 这 并 不 很 
精确 ， 但 是 对 于 现在 来 说 它 已 经 足够 正确 了 。 重 要 的 是 这 一 系列 必须 有 效 地 适合 于 模板 
编译 的 表达 式 是 T 必须 支持 的 implicit interface ( 隐 式 接口 ) 。 


e 对 诸如 operator> 和 operator!= 这 样 的 包含 w 的 函数 的 调用 可 能 伴随 instantiating 
templates (实例 化 模板 ) 以 使 这 些 调用 成 功 。 这 样 的 instantiation (实例 化 ) 发 生 在 编 
译 期 间 。 因 为 用 不 同 的 template parameters (模板 参数 ) 实例 化 function templates (H 
数 模 板 ) 导致 不 同 的 函数 被 调用 ， 因 此 以 compile-time polymorphism (编译 期 多 态 ) 著 
称 。 


即使 你 从 没有 使 用 过 模板 ， 你 也 应 该 熟悉 runtime (运行 期 ) 和 compile-time 
polymorphism (编译 期 多 态 ) 之 间 的 区 别 ， 因 为 它 类 似 于 确定 一 系列 重 载 画 数 中 哪 一 个 应 该 
被 调用 的 过 程 (这 个 发 生 在 编译 期 ) 和 virtual function 《虚拟 函数 ) 调用 的 dynamic 
binding (MASE) (这 个 发 生 在 运行 期 ) 之 间 的 区 别 。explicit ( 显 式 ) 和 imple 


interfaces ( 隐 式 接口 ) ZANE 24 template (模板 ) 有 关 的 新 内 容 ， 需 要 对 他 进行 近 距 
离 的 考察 。 
一 个 explicit interface CEAT) 由 function signatures (函数 识别 特征 ) 组 成 ， 也 就 是 
i, BRA, FRED, REA, SS. PIM, Widget class (类 ) 的 public interface ( 显 式 
接口 ) ， 

class Widget { 

public: 

Widget(); 


virtual ~Wwidget(); 

virtual std::size_t size() const; 
virtual void normalize(); 

void swap(Widget& other); 


由 一 个 constructor (构造 画 数 ) ， 一 个 destructor ( 析 构 画 数 ) , LARBR size, normalize 
和 swap 组 成 ， 再 加 上 parameter types (参数 类 型 ) , return types (返回 类 型 ) Nx wR 
的 constnesses (常量 性 ) 。 ( 它 也 包括 compiler-generated (编译 器 生成 ) 的 copy 
constructor (拷贝 构造 画 数 ) 和 copy assignment operator (拷贝 赋值 运算 符 ) 
ltem 5。) 它 还 可 能 包含 typedefs， 还 有 ， 如 果 你 胆 大 包 天 敢于 违背 Item 22 的 让 data 
members (数据 成 员 ) private (私有 ) 的 建议 ， 即 使 在 这 种 情况 下 ， 这 些 data members ( 数 
据 成 员 ) 也 不 是 。 


参见 





一 个 implicit interface ( 隐 式 接口 ) 有 很 大 不 同 。 它 不 是 基于 function signatures (WRF 2) 
特征 ) 的 。 它 是 由 valid expressions (合法 表达 式 ) 组 成 的 。 再 看 一 下 在 doProcessing 
template 开始 处 的 条 件 : 


template<typename T> 
void doProcessing(T& w) 


if (w.size() > 10 && w != someNastyWidget) { 


对 于 T (w 的 类 型 ) ÉJ implicit interface ( 隐 式 接口 ) 看 起 来 有 如 下 这 些 约束 : 
。 它 必 须 提供 一 个 名 为 size 的 返回 一 个 正 数值 的 member function (AK AEX) 。 


© 它 必 须 支持 一 个 用 于 比较 两 个 类 型 T 的 对 象 的 operator!= WH, (这 里 ， 我 们 假定 
someNastyWidget 的 类 型 为 T。) 


由 于 operator overloading 〈 运 算 符 重 载 ) 的 可 能 性 ， 这 两 个 约束 都 不 必 满 足 。 是 的 ，T 必须 
支持 一 个 size member function (X 7 KZO ， 值 得 提 及 的 是 虽然 这 个 函数 可 以 是 从 一 个 
base class ( 基 类 ) 继承 来 的 。 但 是 这 个 member function (KAWM) 不 需要 返回 一 个 整数 
类 型 。 它 甚至 不 需要 返回 一 个 数值 类 型 。 对 于 这 种 情况 ， 它 甚至 不 需要 返回 一 个 定义 了 
operator> 的 类 型 | 它 要 做 的 全 部 就 是 返回 类 型 X 的 一 个 object (xt) ， 有 一 个 operator> 
可 以 用 一 个 类 型 为 X 的 object (对 象 ) 和 一 个 int (因为 10 为 int 类 型 ) 来 调用 。 这 个 
operator> 不 需要 取得 一 个 类 型 X 的 参数 ， 因 为 它 可 以 取得 一 个 类 型 Y 的 参数 ， 只 要 在 类 型 
X 的 objects (对 象 ) 和 类 型 Y 的 objects (xt&) 之 间 有 一 个 implicit conversion 〈 隐 式 转 
型 ) 就 可 以 了 ! 


类 似 地 ，T 支持 operatorl= 也 是 没有 必要 的 ， 因 为 如 果 operatorl= 取得 一 个 类 型 X 的 
objects (对 象 ) 和 一 个 类 型 Y 的 objects (tk) 是 可 接受 的 一 样 。 只 要 下 能 转型 为 X， 而 
someNastyWidget 的 类 型 能 够 转型 为 Y， 对 operatorl= 的 调用 就 是 合法 的 。 


(一 个 旁 注 : 此 处 的 分 析 没 有 考虑 operator&& 被 重 载 的 可 能 性 ， 这 会 和 类 上 面 的 表达 式 的 含义 
从 与 转换 到 某 些 大 概 完全 不 同 的 东西 。) 
第 一 次 考虑 implicit interfaces ( 隐 式 接口 ) 的 时 候 ， 大 多 数 人 都 会 头疼 ， 但 是 他 们 真 的 不 需 


要 阿司匹林 。implicit interfaces ( 隐 式 接口 ) 简单 地 由 一 套 valid expressions (合法 表达 式 ) 
构成 。 这 些 表 达 式 自身 看 起 来 可 能 很 复杂 ， 但 是 它们 施加 的 约束 通常 是 简单 易 懂 的 。 例 如 ， 


给 出 这 个 条 件 ， 


if (w.size() > 10 && w != someNastyWidget) ... 


关于 functions size, operator>, operator&& 5% operator!= 上 的 约束 很 难说 出 更 多 的 东西 ， 
但 是 要 识别 出 整个 表达 式 的 约束 是 非常 简单 的 。 一 个 if 语句 的 条 件 部 分 必须 是 一 个 boolean 
expression (布尔 表达 式 ) ， 所 以 不 管 "w.size() > 10 && w != someNastyWidget" 所 产生 的 类 

型 涉及 到 的 精确 类 型 ， 它 必须 与 bool 兼容 。 这 就 是 template (模板 ) doProcessing 施加 于 它 
的 type parameter (类 型 参数 ) TT 之 上 的 implicit interface ( 隐 式 接口 ) 的 一 部 分 。 被 
doProcessing 需要 的 interface (接口 ) 的 其 余部 分 是 copy constructor (#8 Mis wR) ， 
normalize 和 swap 的 调用 对 于 类 型 T 的 objects (对 象 ) 来 说 必须 是 合法 的 。 


implicit interface ( 隐 式 接口 ) 对 template (模板 ) 的 parameters (参数 ) 施加 的 影响 正 像 

explicit interfaces ( 显 式 接口 ) 对 一 个 class (#) 的 objects (对 象 ) 施加 的 影响 ， 而 且 这 两 
者 都 在 编译 期 间 被 检查 。 正 像 你 不 能 用 与 它 的 class (类 ) 提供 的 explicit interface ( 显 式 接 
O) 矛盾 的 方法 使 用 object (对象 ) (代码 无 法 编译 ) 一 样 ， 除 非 一 个 object 〈 对 象 ) 支持 

template (模板 ) 所 需要 的 implicit interface (AHO) ， 否 则 你 就 不 能 在 一 个 

template (模板 ) 中 试图 使 用 这 个 object (对 象 ) (代码 还 是 无 法 编译 ) 。 


Things to Remember 


e classes (类 ) 和 templates (模板 ) 都 支持 interfaces (接口 ) 和 polymorphism (多 
AS) 。 


对 于 classes (#) ，interfaces (接口 ) explicit ( 显 式 ) function 
signatures ( 圆 数 识别 特征 ) 为 中 心 的 。polymorphism (多 态 性 ) 通过 virtual 
functions (EWR) 出 现在 运行 期 。 


对 于 template parameters (模板 参数 ) , interfaces (接口 ) implicit (4x) 的 并 基 
于 valid expressions (合法 表达 式 ) 。polymorphism (多 态 性 ) 通过 template 
instantiation (模板 实例 化 ) 和 function overloading resolution (HMB RAAT) 出 现在 
编译 期 。 


Item 42: 理解 typename 的 两 个 含义 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


问题 : 在 下 面 的 template declarations (模板 声明 ) 中 class 和 typename 有 什么 不 同 ? 


template<class T> class Widget; // uses "class" 


template<typename T> class Widget; // uses "typename" 


答案 : 没什么 不 同 。 在 声明 一 个 template type parameter (模板 类 型 参数 ) Wattle, class 和 
typename 意味 着 完全 相同 的 东西 。 一 些 程 序 员 更 喜欢 在 所 有 的 时 间 都 用 class， 因 为 它 更 容 
易 输 入 。 其 他 人 (包括 我 本 人 ) 更 喜欢 typename， 因 为 它 暗示 着 这 个 参数 不 必要 是 一 个 
class type (类 类 型 ) 。 少 数 开 发 者 在 任何 类 型 都 被 允许 的 时 候 使 用 typename， 而 把 class 
保留 给 仅 接 受 user-defined types 〈 用 户 定义 类 型 ) 的 场合 。 但 是 从 C++ 的 观点 看 ，class 和 
typename 在 声明 一 个 template parameter (模板 参数 ) 时 意味 着 完全 相同 的 东西 。 


然而 ，C++ 并 不 总 是 把 class 和 typename 视 为 等 同 的 东西 。 有 时 你 必须 使 用 typename. # 
了 理解 这 一 点 ， 我 们 不 得 不 讨论 你 会 在 一 个 template (模板 ) 中 涉及 到 的 两 种 名 字 。 


假设 我 们 有 一 个 男 数 的 模板 ， 它 能 取得 一 个 STL-compatible container (STL 兼容 容器 ) 中 持 
有 的 能 赋值 给 ints 的 对 象 。 进 一 步 假设 这 个 男 数 只 是 简单 地 打印 它 的 第 二 个 元 素 的 值 。 它 是 
一 个 用 糊涂 的 方法 实现 的 糊涂 的 范 数 ， 而 且 就 像 我 下 面 写 的 ， 它 甚至 不 能 编译 ， 但 是 请 将 这 
些 事先 放 在 一 按 一 有 一 种 方法 能 发 现 我 的 愚蠢 : 


template<typename C> // print 2nd element in 
void print2nd(const C& container) // container; 
// this is not valid C++! 
if (container.size() >= 2) { 
C::const_iterator iter(container.begin()); // get iterator to 1st element 


++iter; // move iter to 2nd element 
int value = *iter; // copy that element to an int 
std::cout << value; // print the int 


FRE 7 x SENHA A local variables 〈 局 部 变量 ) iter 和 value. iter 的 类 型 是 
C::const_iterator, —“MK#i template parameter (模板 参数 ) C 的 类 型 。 一 个 

template (模板 ) 中 的 依赖 于 一 个 template parameter (模板 参数 ) 的 名 字 被 称 为 dependent 
names (依赖 名 字 ) 。 当 一 个 dependent names (依赖 名 字 ) 艇 套 在 一 个 class (类 ) 的 内 部 
时 ， 我 称 它 为 nested dependent name (HREtK MAH) . C::const_iterator 是 一 个 nested 


dependent name (REKMASL) 。 实 际 上 ， 它 是 一 个 nested dependent type name (RE 
依赖 类 型 名 ) ， 也 就 是 说 ， 一 个 涉及 到 一 个 type (类 型 ) 的 nested dependent name (WE 
依赖 名 字 ) 。 


print2nd 中 的 另 一 个 local variable (局 部 变量 ) value 具有 int 类 型 。int 是 一 个 不 依赖 于 任何 
template parameter (模板 参数 ) 的 名 字 。 这 样 的 名 字 以 non-dependent names ( 非 依赖 名 
字 ) 闻名 。 (我 想 不 通 为 什么 他 们 不 称 它 为 independent names (无 依赖 名 字 ) . WR, R 
我 一 样 ， 你 发 现 术语 "non-dependent" 是 一 个 令 人 厌恶 的 东西 ， 你 就 和 我 产生 了 共鸣 ， 但 是 
"non-dependent" 就 是 这 类 名 字 的 术语 ， 所 以 ， 像 我 一 样 ， 转 转眼 睛 放弃 你 的 自我 主张 。) 


nested dependent name (RREKKMES) SSAA x. GUID, Pie Fei) MeL x 
种 方法 开始 print2nd : 


template<typename C> 
void print2nd(const C& container) 


C::const_iterator * x; 


这 看 上 去 好 像 是 我 们 将 x 声明 为 一 个 指向 C::const_iterator 的 local variable (局 部 变量 ) 。 

但 是 它 看 上 去 如 此 仅仅 是 因为 我 们 知道 C::const_iterator 是 一 个 type (类 型 ) 。 但 是 如 果 
C::const_iterator 不 是 一 个 type (类 型 ) 呢 ?如果 C 有 一 个 static data member (静态 数据 成 
A) 碰巧 就 叫做 const_iterator E ?再 如 果 x 碰巧 是 一 个 global variable (全 局 变量 ) MAS 
呢 ?在 这 种 情况 下 ， 上 面 的 代码 就 不 是 声明 一 个 local variable 〈 局 部 变量 ) ， 而 是 成 为 
C::const_iterator RA x! 4A, xE ERA, (AC SAREN, MAS C++ 解析 器 的 人 
必须 考虑 所 有 可 能 的 输入 ， 甚 至 是 思春 的 。 


直到 C 成 为 已 知之 前 ， 没 有 任何 办 法 知道 C::const iterator 到 底 是 不 是 一 个 type (类 型 ) ， 

而 当 template (模板 ) print2nd 被 解析 的 时 候 ，C 还 不 是 已 知 的 。C++ 有 一 条 规则 解决 这 个 
歧义 : 如 果 解 析 器 在 一 个 template (模板 ) 中 遇 到 一 个 nested dependent name (wE 
名 字 ) ， 它 假定 那个 名 字 不 是 一 个 type 〈 类 型 ) ， 除 非 你 用 其 它 方式 告诉 它 。 缺 省 情况 下 ， 

nested dependent name (fREKMAL) TÆ types (类 型 ) 。 (对 于 这 条 规则 有 一 个 例 

外 ， 我 待 会 儿 告诉 你 。 ) 


记 住 这 个 ， 再 看 看 print2nd 的 开头 : 


template<typename C> 
void print2nd(const C& container) 


if (container.size() >= 2) { 


C::const_iterator iter(container.begin()); // this name is assumed to 
ate // not be a type 


这 为 什么 不 是 合法 的 C++ 现在 应 该 很 清楚 了 。iter 的 declaration (声明 ) 仅仅 在 
C::const_iterator 是 一 个 type (类 型 ) 时 才 有 意义 ， 但 是 我 们 没有 告诉 C++ 它 是 ， 而 C++ 就 
假定 它 不 是 。 要 想 转变 这 个 形势 ， 我 们 必须 告诉 C++ C::const_iterator 是 一 个 type (类 


型 ) 。 我 们 将 typename 放 在 紧 挨 着 它 的 前 面 来 做 到 这 一 点 : 


template<typename C> // this is valid C++ 
void print2nd(const C& container) 


if (container.size() >= 2) { 
typename C::const_iterator iter(container.begin()); 


z 
} 
通用 的 规则 很 简单 : 在 你 涉及 到 一 个 在 template (模板 ) 中 的 nested dependent type 


name (EK RBA) 的 任何 时 候 ， 你 必须 把 单词 typename 放 在 紧 挨 着 它 的 前 面 。 〈 重 
申 一 下 ， 我 待 会 儿 要 描述 一 个 例外 。 ) 


typename 应 该 仅仅 被 用 于 标识 nested dependent type name (REKMAHA) ; 其 它 名 字 
不 应 该 用 它 。 例 如 ， 这 是 一 个 取得 一 个 container (容器 ) 和 这 个 container (容器 ) 中 的 一 个 
iterator (和 迭代 器 ) 的 function template (函数 模板 ) 


template<typename C> // typename allowed (as is "class") 
void f(const C& container, // typename not allowed 
typename C::iterator iter); // typename required 


C 不 是 一 个 nested dependent type name (REKMEBE) (CHRERERKMIF-T 
template parameter (模板 参数 ) 的 什么 东西 内 部 的 ) ， 所 以 在 声明 container 时 它 不 必 被 
typename 前 置 ， 但 是 C::iterator 是 一 个 nested dependent type name (HREK MAHA) , 
所 以 它 必需 被 typename 前 置 。 


"typename must precede nested dependent type names" (“typename Ùi AE FREK 
类 型 名 ”) 规则 的 例外 是 typename 不 必 前 置 于 在 一 个 list of base classes ( 基 类 列表 ) 中 的 
或 者 在 一 个 member initialization list (成 员 初 始 化 列表 ) 中 作为 一 个 base classes 

identifier ( 基 类 标识 符 ) 的 nested dependent type name (RER žE) 。 例 如 : 


template<typename T> 
class Derived: public Base<T>::Nested { // base class list: typename not 


public: // allowed 
explicit Derived(int x) 
: Base<T>: :Nested(x) // base class identifier in mem 
{ // init. list: typename not allowed 
typename Base<T>::Nested temp; // use of nested dependent type 
sate // name not in a base class list or 
} // as a base class identifier ina 


// mem. init. list: typename required 


a 


这 桩 的 矛盾 很 伟人 讨厌 ， 但 是 一 旦 你 在 经 历 中 获得 一 点 经 验 ， 你 几乎 不 会 在 意 它 。 


让 我 们 来 看 最 后 一 个 typename 的 例子 ， 因 为 它 在 你 看 到 的 真实 代码 中 具有 代表 性 。 假 设 我 
们 在 写 一 个 取得 一 个 iterator (迭代 器 ) 的 function template (HARR) ， 而 且 我 们 要 做 一 
个 iterator (迭代 器 ) 指向 的 object 〈 对 象 ) 的 局 部 拷贝 temp， 我 们 可 以 这 样 做 : 


template<typename IterT> 
void workWithIterator(IterT iter) 


{ 


typename std::iterator_traits<IterT>::value_type temp(*iter); 


‘ : 


不 要 让 std:titerator_traits<IterT>::value_type 吓 倒 你 。 那 仅仅 是 一 个 standard traits 

class (标准 特性 类 ) (参见 Item 47) 的 使 用 ， 用 C++ 的 说 法 就 是 "the type of thing pointed 
to by objects of type IterT" (“被 类 型 为 lterT 的 对 象 所 指向 的 东西 的 类 型 ") 。 这 个 语句 声明 了 
一 个 与 lterT objects 所 指向 的 东西 类 型 相同 的 local variable (局 部 变量 ) (temp), MHA iter 
所 指向 的 object (对 象 ) 对 temp 进行 了 初始 化 。 如 果 lterT 是 vector<int>::iterator, temp 就 
是 int 类 型 。 如 果 lterT 是 list<string>::iterator，temp 就 是 string 类 型 。 因 为 

std::iterator traits<lterT>::value_type 是 一 个 nested dependent type name (REK y x BY 
名 ) (value_type #7 iterator_traits<IterT> ABB, mH lterT 是 一 个 template 

parameter (模板 参数 ) ) ， 我 们 必须 让 它 被 typename 前 置 。 


如 果 你 觉得 读 std::iterator traits<lterT>::value_type 邻 人 讨厌 ， 就 想象 那个 与 它 相同 的 东西 来 
代表 它 。 如 果 你 像 大 多 数 程序 员 ， 对 多 次 输入 它 感到 和 恐惧 ， 那 么 你 就 需要 创建 一 个 typedef, 
对 于 像 value_type 这 样 的 traits member names (特性 成 员 名 ) (再 次 参见 ltem 47 关于 
traits 的 资料 ) ， 一 个 通用 的 惯例 是 typedef name 与 traits member name 相同 ， 所 以 这 样 的 
一 个 local typedef 通常 定义 成 这 样 : 
template<typename IterT> 
void workwithIterator(IterT iter) 
typedef typename std::iterator_traits<IterT>::value_type value_type; 
value_type temp(*iter); 


T 


很 多 程序 员 最 初 发 现 "typedef typename" 并 列 不 太 和 谐 ， 但 它 是 涉及 nested dependent type 
names (EK MAHA) 规则 的 一 个 合理 的 附带 结果 。 你 会 相当 快 地 习惯 它 。 你 毕竟 有 着 
强大 的 动机 。 你 输入 typename std::iterator traits<lterT>::value_type 需要 多 少时 间 ? 

作为 结束 语 ， 我 应 该 提 及 编译 器 与 编译 器 之 间 对 围绕 typename 的 规则 的 执行 情况 的 不 同 。 

一 些 编译 器 接受 必需 typename 时 它 却 缺失 的 代码 ; 一 些 编译 器 接受 不 许 typename 时 它 却 存 
在 的 代码 ; 还 有 少数 的 (通常 是 老 旧 的 ) 会 拒绝 typename 出 现在 它 必 需 出 现 的 地 方 。 这 就 
意味 着 typename 和 nested dependent type names ( 馈 套 依赖 类 型 名 ) 的 交互 作用 会 导致 一 
些 轻 微 的 可 移植 性 问题 。 


Things to Remember 


e 在 声明 template parameters (模板 参数 ) 时 ，class 和 typename 是 可 互 换 的 。 


e 用 typename 去 标识 nested dependent type names (RE WZ) , {E base class 
lists 〈 基 类 列表 ) 中 或 在 一 个 member initialization list (成 员 初 始 化 列表 ) 中 作为 一 个 
base class identifier ( 基 类 标识 符 ) 时 除外 。 


Item 43: 了 解 如 何 访问 templatized base 
classes (模板 化 基 类 ) 中 的 名 字 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


假设 我 们 要 写 一 个 应 用 程序 ， 它 可 以 把 消息 传送 到 几 个 不 同 的 公司 去 。 消 息 既 可 以 以 加 密 方 
式 也 可 以 以 明文 (不 加 密 ) 的 方式 传送 。 如 果 我 们 有 足够 的 信息 在 编译 期 间 确 定 哪 个 消息 将 
要 发 送 给 哪个 公司 ， 我 们 就 可 以 用 一 个 template-based (模板 基 ) 来 解决 问题 : 


class CompanyA { 
public: 


void sendCleartext(const std::string& msg); 
void sendEncrypted(const std::string& msg); 


ee 


class CompanyB { 
public: 


void sendCleartext(const std::string& msg); 

void sendEncrypted(const std::string& msg); 
}; 
ae // Classes for other companies 
class MsgInfo { ... }; // Class for holding information 

// used to create a message 

template<typename Company> 
class MsgSender { 
public: 

oe // ctors, dtor, etc. 
void sendClear(const MsgInfo& info) 


std::string msg; 
create msg from info; 


Company c; 
c.sendCleartext(msg); 
} 
void sendSecret(const MsgInfo& info) // similar to sendClear, except 
a oman: OF // calls c.sendEncrypted 
}; 


这 个 能 够 很 好 地 工作 ， 但 是 假设 我 们 有 时 需要 在 每 次 发 送 消 息 的 时 候 把 一 些 信息 记录 到 日 志 
中 。 通 过 一 个 derived class (派生 类 ) 可 以 很 简单 地 增加 这 个 功能 ， 下 面 这 个 似乎 是 一 个 合 
理 的 方法 : 


template<typename Company> 
class LoggingMsgSender: public MsgSender<Company> { 

public: 

ee // ctors, dtor, etc. 
void sendClearMsg(const MsgInfo& info) 


{ 


write "before sending" info to the log; 


sendClear (info); // call base class function; 
// this code will not compile! 
write "after sending" info to the log; 


} 


}; 


注意 derived class (派生 类 ) 中 的 message-sending function (消息 发 送 画 数 ) 的 名 字 
(sendClearMsg) 和 与 它 的 base class ( 基 类 ) 中 的 那个 (在 那里 ， 它 被 称 为 sendClear) 不 
同 。 这 是 一 个 好 的 设计 ， 因 为 它 避 开 了 hiding inherited names (隐藏 继承 来 的 名 字 ) 的 问题 
(参见 Item 33) 和 重 定义 一 个 inherited non-virtual function (继承 来 的 非 虚拟 函数 ) 的 与 生 
俱 来 的 问题 (参见 Item 36) 。 但 是 上 面 的 代码 不 能 通过 编译 ， 至 少 在 符合 标准 的 编译 器 上 不 
能 。 这 样 的 编译 器 会 抱怨 sendClear 不 存在 。 我 们 可 以 看 见 sendClear 就 在 base class ( 基 
类 ) 中 ， 但 编译 器 不 会 到 那里 去 寻找 它 。 我 们 有 必要 理解 这 是 为 什么 。 


问题 在 于 当 编译 器 遇 到 class template (类 模板 ) LoggingMsgSender 的 definition (定义 ) 
时 ， 它 们 不 知道 它 从 哪个 class 〈 类 ) 继承 。 当 然 ， 它 是 MsgSender<Company>， 但 是 
Company 是 一 个 template parameter (模板 参数 ) ， 这 个 直到 更 迟 一 些 才 能 被 确定 (4 
LoggingMsgSender 被 实例 化 的 时 候 ) 。 不 知道 Company 是 什么 ， 就 没有 办 法 知道 
class (类 ) MsgSender<Company> 是 什么 样子 的 。 特 别 是 ， 没 有 办 法 知道 它 是 否 有 一 个 
sendClear function (HŽ) 。 


为 了 使 问题 具体 化 ， 假 设 我 们 有 一 个 要 求 加 密 通讯 的 class (3) CompanyZ : 
class CompanyZ { // this class offers no 
public: // sendCleartext function 

void sendEncrypted(const std::string& msg); 


T 


一 般 的 MsgSender template (模板 ) 不 适用 于 CompanyZ， 因 为 那个 模板 提供 一 个 
sendClear function (KW) 对 于 CompanyZ objects (对 象 ) 没有 意义 。 为 了 纠正 这 个 问 
题 ， 我 们 可 以 创建 一 个 MsgSender 针对 CompanyZ 的 特 化 版 本 : 


template<> // a total specialization of 
class MsgSender<CompanyZ> { // MsgSender; the same as the 
public: // general template, except 


eae // sendCleartext is omitted 
void sendSecret(const MsgInfo& info) 
E a 

}; 


注意 这 个 class definition (类 定义 ) 开始 处 的 "template <>" 语法 。 它 表示 这 既 不 是 一 个 
template (模板 ) ， 也 不 是 一 个 standalone class (独立 类 ) 。 正 确 的 说 法 是 ， 它 是 一 个 用 于 
template argument (模板 参数 ) 为 CompanyZ 时 的 MsgSender template (模板 ) 的 
specialized version ( 特 化 版 本 ) 。 这 以 total template specialization (完全 模板 特 化 ) 闻 

名 : template (模板 ) MsgSender 针对 类 型 CompanyZ 被 特 化 ， 而 且 这 个 

RE type parameter (类 型 参数 ) 被 定义 成 了 
CompanyZ， 就 没有 剩 下 能 被 改变 的 其 它 template's parameters (模板 参数 ) 。 





已 知 MsgSender 针对 CompanyZ 被 特 化 ， 再 次 考虑 derived class (派生 类 ) 
LoggingMsgSender : 


template<typename Company> 
class LoggingMsgSender: public MsgSender<Company> { 
public: 


void sendClearMsg(const MsgInfo& info) 
write "before sending" info to the log; 


sendClear (info); // if Company == CompanyZ, 
// this function doesn't exist! 
write "after sending" info to the log; 


} 


}; 


就 像 注释 中 写 的 ， 当 base class ( 基 类 ) 是 MsgSender<CompanyZ> 时 ， 这 里 的 代码 是 无 意 
义 的 ， 因 为 那个 类 没有 提供 sendClear function (WR) 。 这 就 是 为 什么 C++ 拒绝 这 个 调 
用 : 它 认 识 到 base class templates ( 基 类 模板 ) 可 能 被 特 化 ， 而 这 个 特 化 不 一 定 提供 和 
general template (通用 模板 ) 相同 的 interface (接口 ) 。 结 果 ， 它 通常 会 拒绝 在 
templatized base classes (模板 化 基 类 ) 中 寻找 inherited names (继承 来 的 名 字 ) 。 在 某 种 
意义 上 ， 当 我 们 从 Object-oriented C++ 跨越 到 Template C++ (参见 Item 1) 时 ， 

inheritance (继承 ) 会 停止 工作 。 


为 了 重新 启动 它 ， 我 们 必须 以 某 种 方式 使 C++ 的 "don't look in base 
classes" (不 在 模板 基 类 中 寻找 ) 行为 失效 。 有 三 种 方法 可 以 做 到 这 一 点 。 首 先 ， 你 可 以 在 被 
调用 的 base class functions (4# ž #0 前面 加 上 "this->" : 


template<typename Company> 
class LoggingMsgSender: public MsgSender<Company> { 
public: 


void sendClearMsg(const MsgInfo& info) 
write "before sending" info to the log; 


this->sendClear(info); // okay, assumes that 
// sendClear will be inherited 
write "after sending" info to the log; 


} 


}; 


第 二 ， 你 可 以 使 用 一 个 using declaration， 如 果 你 已 经 读 过 ltem 33， 这 应 该 是 你 很 熟悉 的 一 
种 解决 方案 。 那 个 Item 解释 了 using declarations 如 何 将 被 隐藏 的 base class names ( 基 类 
名 字 ) 引入 到 一 个 derived class (派生 类 ) 领域 中 。 因 此 我 们 可 以 这 样 写 sendClearMsg : 


template<typename Company> 
class LoggingMsgSender: public MsgSender<Company> { 
public: 
using MsgSender<Company>: :sendClear; // tell compilers to assume 
// that sendClear is in the 
// base class 
void sendClearMsg(const MsgInfo& info) 


{ 


sendClear (info); // okay, assumes that 
// sendClear will be inherited 


Ean 


(& % using declaration 在 这 里 和 Item 33 中 都 可 以 工作 ， 但 要 解决 的 问题 是 不 同 的 。 
的 情形 不 是 base class names ( 基 类 名 字 ) 被 derived class names (派生 类 名 字 ) 隐藏 ， 而 
是 如 果 我 们 不 告诉 它 去 做 ， 编 译 器 就 不 会 搜索 base class 领域 。) 


最 后 一 个 让 你 的 代码 通过 编译 的 办 法 是 显 式 指定 被 调用 的 函数 是 在 base class ( 基 类 ) 中 
的 : 


template<typename Company> 
class LoggingMsgSender: public MsgSender<Company> { 


public: 
void sendClearMsg(const MsgInfo& info) 
{ 
MsgSender<Company>: :sendClear (info); // okay, assumes that 
peer // sendClear will be 
} // inherited 


Ta 


通常 这 是 一 个 解决 这 个 问题 的 最 不 合 人 心 的 方法 ， 因 为 如 果 被 调用 函数 是 virtual (虚拟 ) 
的 ， 显 式 限 定 会 关闭 virtual binding (虚拟 绑 定 ) 行为 。 


从 名 字 可 见 性 的 观点 来 看 ， 这 里 每 一 个 方法 都 做 了 同样 的 事情 : 它 向 编译 器 保证 任何 后 继 的 
base class template ( 基 类 模板 ) 的 specializations ( 特 化 ) 都 将 支持 general template (Ñ 
用 模板 ) 提供 的 interface (接口 ) 。 所 有 的 编译 器 在 解析 一 个 像 LoggingMsgSender 这 样 的 
derived class template (派生 类 模板 ) 时 ， 这 样 一 种 保证 都 是 必要 的 ， 但 是 如 果 保 证 被 证 实 
不 成 立 ， 真 相 将 在 后 继 的 编译 过 程 中 暴露 。 例 如 ， 如 果 后 面 的 源 代码 中 包含 这 些 ， 


LoggingMsgSender<CompanyZ> zMsgSender; 
MsgInfo msgData; 
// put info in msgData 


zMsgSender .sendClearMsg(msgData) ; // error! won't compile 


xt sendClearMsg 的 调用 将 不 能 编译 ， 因 为 在 此 刻 ， 编 译 器 知道 base class 〈 基 类 ) 是 
template specialization (模板 特 化 ) MsgSender<CompanyZ>， 它 们 也 知道 那个 class (类 ) 
没有 提供 sendClearMsg 试图 调用 的 sendClear function (H8) 。 


从 根本 上 说 ， 问 题 就 是 编译 器 是 早 些 ( 当 derived class template definitions (派生 类 模板 定 
SL) 被 解析 的 时 候 ) 诊断 对 base class members ( 基 类 成 员 ) 的 非法 引用 ， 还 是 晚 些 时 候 

( 当 那 些 templates (模板 ) 被 特定 的 template arguments (模板 参数 ) 实例 化 的 时 候 ) 再 进 
行 。C++ 的 方针 是 宁愿 早 诊断 ， 而 这 就 是 为 什么 当 那 些 classes (类 ) 被 从 templates ( 模 
板 ) 实例 化 的 时 候 ， 它 假装 不 知道 base classes ( 基 类 ) 的 内 容 。 


Things to Remember 


e 在 derived class templates (派生 类 模板 ) 中 ， 可 以 经 由 "this->" 前 级 ， 经 由 using 
declarations， 或 经 由 一 个 explicit base class qualification ( 显 式 基 类 限定 ) 引用 base 
class templates ( 基 类 模板 ) 中 的 名 字 。 


Item 44: M templates (模板 ) 中 分 离 出 
parameter-independent (参数 无 关 ) 的 代码 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


templates (模板 ) 是 节省 时 间 和 避免 代码 重复 的 极 好 方法 。 不 必 再 输入 20 个 相似 的 
classes， 每 一 个 包含 15 个 member functions (AK APR) ， 你 可 以 输入 一 个 cass 
template (类 模板 ) ， 并 让 编译 器 实例 化 出 你 需要 的 20 个 specific classes (特定 类 ) 和 300 
个 函数 。 (class template (类 模板 ) 的 member functions (AK ABM) 只 有 被 使 用 时 才 会 被 
隐 式 实例 化 ， 所 以 只 有 在 每 一 个 函数 都 被 实际 使 用 时 ， 你 才 会 得 到 全 部 300 member 
functions (AK ñ IŽ) 。) function templates (函数 模板 ) 也 有 相似 的 魅力 。 不 必 再 写 很 多 
函数 ， 你 可 以 写 一 个 function templates (HAURR) 并 让 编译 器 做 其 余 的 事 。 这 不 是 很 重要 
的 技术 吗 ? 


是 的 ， 不 错 .….. 有 时 。 如 果 你 不 小 心 ， 使 用 templates (模板 ) 可 能 导致 code bloat (代码 脱 
K) : 重复 的 (或 几乎 重复 的 ) 的 代码 ， 数 据 ， 或 两 者 都 有 的 二 进 制 码 。 结 果 会 使 源 代 码 看 
上 去 紧凑 而 整洁 ， 但 是 目标 代码 膝 肿 而 松散 。 腔 肿 而 松散 很 少 会 成 为 时 尚 ， 所 以 你 需要 了 解 
如 何 避 免 这 样 的 二 进 制 扩张 。 


你 的 主要 工具 有 一 个 有 气势 的 名 字 commonality and variability analysis (通用 性 与 可 变性 分 
Nt) ， 但 是 关于 这 个 想法 并 没有 什么 有 气势 的 东西 。 即 使 在 你 的 职业 生涯 中 从 来 没有 使 用 过 
模板 ， 你 也 应 该 从 始 至 终 做 这 样 的 分 析 。 


当 你 写 一 个 画 数 ， 而 且 你 意识 到 这 个 画 数 的 实现 的 某 些 部 分 和 另 一 个 本 数 的 实现 本 质 上 是 相 
同 的 ， 你 会 仅仅 复制 代码 吗 ? 当然 不 。 你 从 这 两 个 画 数 中 分 离 出 通用 的 代码 ， 放 到 第 三 个 函 
数 中 ， 并 让 那 两 个 函数 来 调用 这 个 新 的 函数 。 也 就 是 说 ， 你 分 析 那 两 个 函数 以 找 出 那些 通用 
和 变化 的 构件 ， 你 把 通用 的 构件 移入 一 个 新 的 函数 ， 并 把 变化 的 构件 保留 在 原画 数 中 。 类似 
地 ， 如 果 你 写 一 个 class， 而 且 你 意识 到 这 个 class 的 某 些 构件 和 另 一 个 class 的 构件 是 相同 
的 ， 你 不 要 复制 那些 通用 构件 。 作 为 替代 ， 你 把 通用 构件 移入 一 个 新 的 class 中 ， 然 后 你 使 用 
inheritance (继承 ) 或 composition (复合 ) (参见 ltems 32，38 和 39) 使 得 原来 的 
classes 可 以 访问 这 些 通用 特性 。 原 来 的 classes 中 不 同 的 构件 一 一 变化 的 构件 一 一 仍 保留 在 
它们 原来 的 位 置 。 


在 写 templates (模板 ) 时 ， 你 要 做 同样 的 分 析 ， 而 且 用 同样 的 方法 避免 重复 ， 但 这 里 有 一 个 
技巧 。 在 non-template code ( 非 模 板 代 码 ) 中 ， 重 复 是 显 式 的 : 你 可 以 看 到 两 个 函数 或 两 个 
类 之 间 存 在 重复 。 在 template code (模板 代码 ) 中 。 重 复 是 隐 式 的 : 仅 有 一 份 template ( 模 


AR) 源 代码 的 拷贝 ， 所 以 你 必须 培养 自己 去 判断 在 一 个 template (模板 ) 被 实例 化 多 次 后 可 
能 发 生 的 重复 。 


例如 ， 假 设 你 要 为 固定 大 小 的 square matrices (EAH) 写 一 个 templates (模板 ) ， 其 
中 ， 要 支持 matrix inversion (和 矩阵 转 置 ) 。 


template<typename T, // template for n x n matrices of 
std::size_t n> // objects of type T; see below for info 
class SquareMatrix { // on the size_t parameter 
public: 
void invert(); // invert the matrix in place 


这 个 template (模板 ) 取得 一 个 type parameter (类 型 参数 ) T， 但 是 它 还 有 一 个 类 型 为 
size_t 的 参数 一 一 一 个 non-type parameter ( 非 类 型 参数 ) 。non-type parameter ( 非 类 型 参 
数 ) 比 type parameter (类 型 参数 ) 更 不 通用 ， 但 是 它们 是 完全 合法 的 ， 而 且 ， 就 像 在 本 例 
中 ， 它 们 可 以 非常 自然 。 


现在 考虑 以 下 代码 : 


SquareMatrix<double, 5> sm1; 
sm1.invert(); // call SquareMatrix<double, 5>::invert 
SquareMatrix<double, 10> sm2; 


sm2.invert(); // call SquareMatrix<double, 10>::invert 


这 里 将 有 两 个 invert 的 拷贝 被 实例 化 。 这 两 个 函数 不 是 相同 的 ， 因 为 一 个 作用 于 5 x 5 和 矩阵 ， 
而 另 一 个 作用 于 10 x 10 矩阵 ， 但 是 除了 常数 5 和 10 以 外 ， 这 两 个 范 数 是 相同 的 。 这 是 一 71 
R Æ template-induced code bloat (模板 导致 的 代码 膨胀 ) 的 经 典 方法 。 


如 果 你 看 到 两 个 函数 除了 一 个 版 本 使 用 了 5 而 另 一 个 使 用 了 10 之 外 ， 对 应 字符 全 部 相等 ， 你 
该 怎么 做 呢 ? 你 的 直觉 让 你 创建 一 个 取得 一 个 值 作为 一 个 参数 的 函数 版 本 ， 然 后 用 5 或 10 调 
用 这 个 参数 化 的 函数 以 代 蔡 复制 代码 。 你 的 直觉 为 你 提供 了 很 好 的 方法 ! 以 下 是 一 个 初步 过 
关 的 SquareMatrix 的 做 法 : 


template<typename T> // size-independent base class for 
class SquareMatrixBase { // square matrices 
protected: 


void invert(std::size_t matrixSize); // invert matrix of the given size 


ee 


template< typename T, std::size_t n> 
class SquareMatrix: private SquareMatrixBase<T> { 
private: 
using SquareMatrixBase<T>: :invert; // avoid hiding base version of 
// invert; see Item 33 
public: 


void invert() { this->invert(n); } // make inline call to base class 


WP // version of invert; see below 
// for why "this->" is here 


就 像 你 能 看 到 的 ，invert 的 参数 化 版 本 是 在 一 个 base class ($ #) SquareMatrixBase 中 
的 。 与 SquareMatrix —##, SquareMatrixBase 是 一 个 template (模板 ) ， 但 与 
SquareMatrix 不 一 样 的 是 ， 它 参数 化 的 仅仅 是 和 矩阵 中 的 对 象 的 类 型 ， 而 没有 和 矩阵 的 大 小 。 
此 ， 所 有 持 有 一 个 给 定 对 象 类 型 的 矩阵 将 共享 一 个 单一 的 SquareMatrixBase class。 从而， 
它们 共享 invert 在 那个 class 中 的 版 本 的 单一 拷贝 。 


SquareMatrixBase::invert 仅仅 是 一 个 计划 用 于 derived classes (派生 类 ) 以 避免 代码 重复 的 
方法 ， 所 以 它 是 protected 的 而 不 是 public 的 。 调 用 它 的 额外 成 本 应 该 为 需 ， 因 为 derived 
classes (派生 类 ) 的 inverts 使 用 inline functions (A sXE#X) 调用 base class ( 基 类 ) 的 版 
A, (这 个 inline 是 隐 式 的 一 一 参见 Item 30。) ZERURA T "this->" 标记 ， 因 为 就 像 
Item 43 解释 的 ， 如 果 不 这 样 ， 在 templatized base classes (模板 化 基 类 ) 中 的 函数 名 ( 诸 
如 SquareMatrixBase<T>) 被 derived classes (派生 类 ) 隐藏 。 还 要 注意 SquareMatrix 和 
SquareMatrixBase 之 间 的 继承 关系 是 private 的 。 这 准确 地 反映 了 base class ( 基 类 ) 存在 
的 理由 仅仅 是 简化 derived classes (派生 类 ) 的 实现 的 事实 ， 而 不 是 表示 SquareMatrix 和 
SquareMatrixBase 之 间 的 一 个 概念 上 的 is-a 关系 。 (关于 private inheritance (私有 继承 ) 
的 信息 ， 参 见 ltem 39。) 





迄今 为 止 ， 还 不 错 ， 但 是 有 一 个 棘手 的 问题 我 们 还 没有 提 及 。SquareMatrixBase::invert 怎样 
知道 应 操作 什么 数据 ? 它 从 它 的 参数 知道 矩阵 的 大 小 ， 但 是 它 怎 样 知道 一 个 特定 矩阵 的 数据 
在 哪里 呢 ? 大 概 只 有 derived class (派生 类 ) 才 知 道 这 些 。derived class 〈 派 生 类 ) 如 何 把 
这 些 传达 给 base class ( 基 类 ) 以 便于 base class (HEX) 能 够 做 这 个 转 置 呢 ? 


一 种 可 能 是 为 SquareMatrixBase::invert 增加 另 一 个 的 参数 ， 也 许 是 一 个 指向 存储 矩阵 数据 的 
内 存 块 的 开始 位 置 的 指针 。 这 样 可 以 工作 ， 但 是 十 有 八 九 ，invert 不 是 SquareMatrix 中 仅 有 

的 能 被 写成 一 种 size-independent (大 小 无 关 ) 的 方式 并 移入 SquareMatrixBase BEE. 40 
果 有 几 个 这 样 的 画 数 ， 全 都 需要 一 种 找到 持 有 矩阵 内 的 值 的 内 存 的 方法 。 我 们 可 以 为 它们 全 

都 增加 一 个 额外 的 参数 ， 但 是 我 们 一 再 重复 地 告诉 SquareMatrixBase 同样 的 信息 。 这 看 上 去 
不 太 正 常 。 


一 个 可 蔡 换 方案 是 让 SquareMatrixBase 存储 一 个 指向 矩阵 的 值 的 内 存 区 域 的 指针 。 而 且 一 旦 
它 存储 了 这 个 指针 ， 它 同样 也 可 以 存储 矩阵 大 小 。 最 后 得 到 的 设计 大 致 就 像 这 样 : 


template<typename T> 
class SquareMatrixBase { 


protected: 
SquareMatrixBase(std::size_t n, T *pMem) // store matrix size and a 
: size(n), pData(pMem) {} // ptr to matrix values 
void setDataPtr(T *ptr) { pData = ptr; } // reassign pData 
private: 
std::size_t size; // size of matrix 
T *pData; // pointer to matrix values 
}; 


这 样 就 是 让 derived classes (派生 类 ) 决定 如 何 分 配 内 存 。 某 些 实现 可 能 决定 直接 在 
SquareMatrix object 内 部 存储 矩阵 数据 : 


template<typename T, std::size_t n> 
class SquareMatrix: private SquareMatrixBase<T> { 


public: 

SquareMatrix() // send matrix size and 

: SquareMatrixBase<T>(n, data) {} // data ptr to base class 
private: 


T data[n*n]; 


$ 


这 种 类 型 的 objects 不 需要 dynamic memory allocation (动态 内 存 分 配 ) ， 但 是 这 些 objects 
本 身 可 能 会 非常 大 。 一 个 可 选 方案 是 将 每 一 个 矩阵 的 数据 放 到 heap (HE) E: 


template<typename T, std::size_t n> 
class SquareMatrix: private SquareMatrixBase<T> { 


public: 
SquareMatrix() // set base class data ptr to null, 
: SquareMatrixBase<T>(n, 0), // allocate memory for matrix 

pData(new T[n*n]) // values, save a ptr to the 

{ this->setDataPtr(pData.get()); } // memory, and give a copy of it 
itn // to the base class 

private: 
boost: :scoped_array<T> pData; // see Item 13 for info on 

}; // boost: :scoped_array 


无 论 数据 存储 在 哪里 ， 从 膨胀 的 观点 来 看 关键 的 结果 在 于 : 现在 SquareMatrix 的 许多 一 一 也 
许 是 全 部 member functions (AX A HR) 可 以 简单 地 inline 调用 它 的 base class 
versions 〈 基 类 版 本 ) ， 而 这 个 版 本 是 与 其 它 所 有 持 有 相同 数据 类 型 的 矩阵 共享 的 ， 而 无 论 它 
们 的 大 小 。 与 此 同时 ， 不 同 大 小 的 SquareMatrix objects 是 截然 不 同 的 类 型 ， 所 以 ， 例 如 ， 
即使 SquareMatrix<double, 5> 和 SquareMatrix<double, 10> objects 使 用 





SquareMatrixBase<double> 中 同样 的 member functions (AK ABM) ， 也 没有 机 会 将 一 个 
SquareMatrix<double, 5> object 传送 给 一 个 期 望 一 个 SquareMatrix<double, 10> AYER. íR 
好 ， 不 是 吗 ? 


很 好 ， 是 的 ， 但 不 是 免费 的 。 将 和 矩阵 大 小 硬性 国定 在 其 中 的 invert 版 本 很 可 能 比 将 大 小 作为 
一 个 函数 参数 传人 或 存储 在 object 中 的 共享 版 本 能 产生 更 好 的 代码 。 例 如 ， 在 size- 
specific (特定 大 小 ) 的 版 本 中 ，sizes (大 小 ) 将 成 为 compile-time constants (编译 期 常 
数 ) ， 因 此 适用 于 像 constant propagation 这 样 的 优化 ， 包 括 将 它们 作为 immediate 
operands (立即 操作 数 ) 典 入 到 生成 的 指令 中 。 在 size-independent version (大 小 无 关 版 
本 ) 中 这 是 不 可 能 做 到 的 。 


另 一 方面 ， 将 唯一 的 invert 的 版 本 用 于 多 种 和 矩 阵 大 小 缩小 了 可 执行 码 的 大 小 ， 而 且 还 能 缩小 
程序 的 working set (工作 区 ) 大 小 以 及 改善 instruction cache (指令 缓存 ) 中 的 locality of 
reference (引用 的 局 部 性 ) 。 这 些 能 使 程序 运行 得 更 快 ， 超 额 偿 还 了 失去 的 针对 invert 的 
size-specific versions (特定 大 小 版 本 ) 的 任何 优化 。 哪 一 个 效果 更 划算 ? 唯一 的 分 辩 方 法 就 
是 在 你 的 特定 平台 和 典型 数据 集 上 试验 两 种 方法 并 观察 其 行为 。 


另 一 个 效率 考虑 关系 到 objects 的 大 小 。 如 果 你 不 小 心 ， 将 函数 的 size-independent 版 本 (大 
小 无 关 版 本 ) 上 移 到 一 个 base class ( 基 类 ) 中 会 增加 每 一 个 object 的 整体 大 小 。 例 如 ， 在 
我 刚才 展示 的 代码 中 ， 即 使 每 一 个 derived class (派生 类 ) 都 已 经 有 了 一 个 取得 数据 的 方 
法 ， 每 一 个 SquareMatrix object 都 还 有 一 个 指向 它 的 数据 的 指针 存在 于 SquareMatrixBase 
class 中 ， 这 为 每 一 个 SquareMatrix object 至 少 增 加 了 一 个 指针 的 大 小 。 通 过 改变 设计 使 这 
些 指针 不 再 必需 是 有 可 能 的 ， 但 是 ， 这 又 是 一 桩 交易 。 例 如 ， 让 base class (HX) 存储 一 
个 指向 和 矩阵 数据 的 protected 指针 导致 在 ltem 22 中 描述 的 封装 性 的 降低 。 它 也 可 能 导致 资源 
管理 复杂 化 : 如 果 base class (AX) 存储 了 一 个 指向 矩阵 数据 的 指针 ， 但 是 那些 数据 既 可 
以 是 动态 分 配 的 也 可 以 是 物理 地 存储 于 derived class object (派生 类 对 象 ) 之 内 的 (就 像 我 
们 看 到 的 ) ， 它 如 何 决 定 这 个 指针 是 否 应 该 被 删除 ? 这 样 的 问题 有 答案 ， 但 是 你 越 想 让 它们 
更 加 精巧 一 些 ， 它 就 会 变 成 更 复杂 的 事情 。 在 某 些 条 件 下 ， 少 量 的 代码 重复 就 像 是 一 种 解 
脱 。 

本 Item 只 讨论 了 由 于 non-type template parameters ( 非 类 型 模板 参数 ) 引起 的 膨胀 ， 但 是 
type parameters (类 型 参数 ) 也 能 导致 膨胀 。 例 如 ， 在 很 多 平台 上 ，int 和 long 有 相同 的 二 
进 制 表 示 ， 所 以 ， 可 以 说 ，vector<int> 和 vector<long> 的 member functions (AK ARAL) 很 
可 能 是 相同 的 一 一 膨胀 的 恰到好处 的 解释 。 某 些 连 接 程序 会 合并 同样 的 画 数 实现 ， 还 有 一 些 
会 ， 而 这 就 意味 着 在 一 些 环境 上 一 些 模板 在 int 和 long 上 都 被 实例 化 而 能 够 引起 代码 重 
复 。 类 似 地 ， 在 大 多 数 平台 上 ， 所 有 的 指针 类 型 有 相同 的 二 进 制 表 示 ， 所 以 持 有 指针 类 型 的 
模板 〈 例 如 ，list<int*>，list<const int*>, list<SquareMatrix<long, 3>*> 等 ) 应 该 通常 可 以 使 
用 每 一 个 member function (AK ARR) 的 单一 的 底层 实现 。 典 型 情况 下 ， 这 意味 着 与 
strongly typed pointers ( 强 类 型 指针 ) (也 就 是 T* 指针 ) 一 起 工作 的 member functions (成 
ABR) 可 以 通过 让 它们 调用 与 untyped pointers (无 类 型 指针 ) (也 就 是 void* 指针 ) 一 起 
工作 的 函数 来 实现 。 一 些 标准 C++ 库 的 实现 对 于 像 vector，deque 和 list 这 样 的 模板 就 是 这 
样 做 的 。 如 果 你 关心 起 因 于 你 的 模板 的 代码 膨胀 ， 你 可 能 需要 用 同样 的 做 法 开发 模板 。 





Things to Remember 


e templates (模板 ) 产生 多 个 classes 和 多 个 functions， 所 以 一 些 不 依赖 于 template 
parameter (模板 参数 ) 的 模板 代码 会 引起 膨胀 。 


e non-type template parameters ( 非 类 型 模板 参数 ) 引起 的 膨胀 常常 可 以 通过 用 function 
parameters (HABA) 或 class data members (类 数据 成 员 ) 替换 template 
parameters (模板 参数 ) 而 消除 。 


e type parameters (类 型 参数 ) 引起 的 膨胀 可 以 通过 让 具有 相同 的 二 进 制 表示 的 实例 化 类 
型 共享 实现 而 减少 。 


Item 45: 用 member function templates (Ax ñ E 
数 模板 ) 接受 "all compatible types" (MARE 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


smart pointers (智能 指针 ) 是 行为 很 像 指针 但 是 增加 了 指针 没有 提供 的 功能 的 objects。 例 
如 ，ltem 13 阐述 了 标准 auto_ptr 和 tr1::shared_ptr 是 怎样 被 应 用 于 在 恰当 的 时 间 自 动 删除 的 
heap-based resources (基于 挫 的 资源 ) 的 。STL containers 内 的 iterators OIRA) 几乎 始 
终 是 smart pointers (智能 指针 ) ; 你 绝对 不 能 指望 用 "++" 将 一 个 built-in pointer (内 建 指 
$+) 从 一 个 linked list (线性 链表 ) 的 一 个 节点 移动 到 下 一 个 ， 但 是 list::iterators 可 以 做 到 。 


real pointers (真正 的 指针 ) 做 得 很 好 的 一 件 事 是 支持 implicit conversions ( 隐 式 转换 ) 。 
derived class pointers (派生 类 指针 ) 隐 式 转换 到 base class pointers ( 基 类 指针 ) , 
pointers to non-const objects (指向 非常 量 对 象 的 指针 ) 转换 到 pointers to const objects (48 
向 常量 对 象 的 指针 ) ， 等 等 。 例 如 ， 考 虑 在 一 个 three-level hierarchy (三 层 继承 体系 ) 中 能 
发 生 的 一 些 转换 : 


class Top { ... }; 

class Middle: public Top { ... }; 

class Bottom: public Middle { ... }; 

Top *pti = new Middle; // convert Middle* => Top* 
Top *pt2 = new Bottom; // convert Bottom* => Top* 
const Top *pct2 = pti; // convert Top* => const Top* 


在 user-defined smart pointer classes 〈 用 户 定义 智能 指针 类 ) 中 模仿 这 些 转换 是 需要 技巧 
的 。 我 们 要 让 下 面 的 代码 能 够 编译 : 


template<typename T> 
class SmartPtr { 


public: // smart pointers are typically 
explicit SmartPtr(T *realPtr); // initialized by built-in pointers 

J; 

SmartPtr<Top> pti = // convert SmartPtr<Middle> => 

SmartPtr<Middle>(new Middle); // SmartPtr<Top> 

SmartPtr<Top> pt2 = // convert SmartPtr<Bottom> => 

SmartPtr<Bottom>(new Bottom); // SmartPtr<Top> 

SmartPtr<const Top> pct2 = pti; // convert SmartPtr<Top> => 


// SmartPtr<const Top> 


在 同一 个 template (模板 ) 的 不 同 instantiations (实例 化 ) 之 间 没 有 inherent 

relationship (继承 关系 ) ， 所 以 编译 器 认为 SmartPtr<Middle> 和 SmartPtr<Top> 是 完全 不 
同 的 classes， 并 不 比 (比方 说 ) vector<float> 和 Widget 的 关系 更 近 。 为 了 得 到 我 们 想 要 的 
在 SmartPtr classes 之 间 的 转换 ， 我 们 必须 显 式 地 为 它们 编程 。 


在 上 面 的 smart pointer (智能 指针 ) 的 示例 代码 中 ， 每 一 个 语句 创建 一 个 新 的 smart pointer 
object (智能 指针 对 象 ;， 所 以 现在 我 们 就 集中 于 我 们 如 何 写 smart pointer constructors ( 智 
能 指针 的 构造 画 数 ) ， 让 它 以 我 们 想 要 的 方式 运转 。 一 个 关键 的 事实 是 我 们 无 法 写 出 我 们 需 
要 的 全 部 constructors GAER) 。 在 上 面 的 hierarchy (继承 体系 ) 中 ， 我 们 能 从 一 个 
SmartPtr<Middle> 或 一 个 SmartPtr<Bottom> 构造 出 一 个 SmartPtr<Top>， 但 是 如 果 将 来 这 
个 hierarchy (继承 体系 ) 被 扩充 ，SmartPtr<Top> objects 还 必须 能 从 其 它 smart pointer 
types (智能 指针 类 型 ) 构造 出 来 。 例 如 ， 如 果 我 们 后 来 加 入 


class BelowBottom: public Bottom { ... }; 


我 们 就 需要 支持 从 SmartPtr<BelowBottom> objects 到 SmartPtr<Top> objects 的 创建 ， 而 且 
我 们 当然 不 希望 为 了 做 到 这 一 点 而 必须 改变 SmartPtr template. 


大 体 上 ， 我 们 需要 的 constructors (构造 函数 ) 的 数量 是 无 限 的 。 因 为 一 个 template (模板 ) 
能 被 实例 化 而 产生 无 数 个 函数 ， 所 以 好 像 我 们 不 需要 为 SmartPtr 提供 一 个 constructor 
function (ie RRB) ， 我 们 需要 一 个 constructor template (iS HAAR) 。 这 样 的 
templates (模板 ) 是 member function templates (KARR) (常常 被 恰如其分 地 称 为 
member templates (成 员 模 板 ) ) 一 一 生成 一 个 class 的 member functions (成 员 画 数 ) 的 
templates (模板 ) 的 范例 : 


template<typename T> 
class SmartPtr { 


public: 
template<typename U> // member template 
SmartPtr(const SmartPtr<U>& other); // for a "generalized 
conte // copy constructor" 
J; 


这 就 是 说 对 于 每 一 种 类 型 T 和 每 一 种 类 型 U， 都 能 从 一 个 SmartPtr<U> 创建 出 一 个 
SmartPtr<T>， 因 为 SmartPtr<T> 有 一 个 取得 一 个 SmartPtr<U> 参数 的 constructor (éR 
数 ) 。 像 这 样 的 constructor (WERA) 一 一 从 一 个 类 型 是 同一 个 template (模板 ) 的 不 同 
实例 化 的 object 创建 另 一 个 object 的 constructor AERO (例如 ， 从 一 个 SmartPtr<U> 
创建 一 个 SmartPtr<T>) 一 一 有 时 被 称 为 generalized copy constructors ( 泛 型 化 拷贝 构造 男 
数 ) 。 


上 面 的 generalized copy constructor ( 泛 型 化 拷贝 构造 画 数 ) 没有 被 声明 为 explicit ( 显 式 ) 
的 。 这 是 故意 为 之 的 。built-in pointer types (内 建 指 针 类 型 ) 之 间 的 类 型 转换 (例如 ， 从 派 
生 类 指针 到 基 类 指针 ) 是 隐 式 的 和 不 需要 cast (强制 转型 ) 的 ， 所 以 让 smart pointers (智能 


指针 ) 模仿 这 一 行为 是 合理 的 。 在 templatized constructor (Rib EnO 中 省 略 
explicit 正好 做 到 这 一 点 。 


作为 声明 ，SmartPtr 的 generalized copy constructor ( 泛 型 化 拷贝 构造 本 数 ) 提供 的 东西 比 
我 们 想 要 的 还 多 。 是 的 ， 我 们 需要 能 够 从 一 个 SmartPtr<Bottom> 创建 一 个 SmartPtr<Top>， 
但 是 我 们 不 需要 能 够 从 一 个 SmartPtr<Top> 创建 一 个 SmartPtr<Bottom>， 这 就 像 颠 倒 public 
inheritance (公有 继承 ) 的 含义 (参见 Item 32) 。 我 们 也 不 需要 能 够 从 一 个 
SmartPtr<double> 创建 一 个 SmartPtr<int>， 因 为 这 和 从 int* 到 double* 的 implicit 
conversion ( 隐 式 转换 ) 是 不 相称 的 。 我 们 必须 设法 过 滤 从 这 个 member template (成 员 模 
板 ) 生成 的 member functions (AK A ENA) 的 群体 。 


假如 SmartPtr 跟随 auto_ptr 和 tr1::shared_ptr 的 脚步 ， 提 供 一 个 返回 被 这 个 smart 

pointer (智能 指针 ) 持 有 的 built-in pointer (内 建 指 针 ) 的 拷贝 的 get member function (get 
MARR) (参见 ltem 15) ， 我 们 可 以 用 constructor template (Mis BARR) 的 实现 将 
转换 限定 在 我 们 想 要 的 范围 : 


template<typename T> 
class SmartPtr { 


public: 
template<typename U> 
SmartPtr(const SmartPtr<U>& other) // initialize this held ptr 
: heldPtr(other.get()) { ... } // with other's held ptr 


T* get() const { return heldPtr; } 


private: // built-in pointer held 
T *heldPtr; // by the SmartPtr 


}; 


我 们 通过 member initialization list (成 员 初 始 化 列表 ) ， 用 SmartPtr<U> 持 有 的 类 型 为 U* 的 
指针 初始 化 SmartPtr<T> 的 类 型 为 T* 的 data member (数据 成 员 ) 。 这 只 有 在 “存在 一 个 从 
一 个 U* 指针 到 一 个 T* 指针 的 implicit conversion ( 隐 式 转换 ) ”的 条 件 下 才能 编译 ， 而 这 正 
是 我 们 想 要 的 。 最 终 的 效果 就 是 SmartPtr<T> 现在 有 一 个 generalized copy constructor ( 泛 
Ab AHH) ， 它 只 有 在 传 入 一 个 compatible type (兼容 类 型 ) 的 参数 时 才能 编译 。 


member function templates (ak A HBA) 的 用 途 并 不 限于 constructors (Mie HRM) 。 它 
们 的 另 一 个 常见 的 任务 是 用 于 支持 assignment (赋值 ) 。 例 如 ，TR1 的 shared_ptr (BRE 
见 ltem 13) 支持 从 所 有 兼容 的 built-in pointers (内 建 指针 ) , tr1::shared_ptrs, auto_ptrs 
和 tr1::weak_ptrs (参见 Item 54) 构造 ， 以 及 从 除 tr1::weak_ptrs 以 外 所 有 这 些 赋值 。 这 里 
是 从 TR1 规范 中 摘录 出 来 的 一 段 关 于 tr1::shared_ptr 的 内 容 ， 包 括 它 在 声明 template 
parameters (模板 参数 ) 时 使 用 class 而 不 是 typename 的 偏好 。 (就 像 Item 42 中 阐述 的 ， 
在 这 里 的 上 下 文 环 境 中 ， 它 们 的 含义 严格 一 致 。) 


template<class T> class shared_ptr { 


public: 
template<class Y> // construct from 
explicit shared_ptr(Y * p); // any compatible 
template<class Y> // built-in pointer, 
shared_ptr(shared_ptr<Y> const& r); // shared_ptr, 
template<class Y> // weak_ptr, or 
explicit shared_ptr(weak_ptr<Y> const& r); // auto_ptr 


template<class Y> 
explicit shared_ptr(auto_ptr<Y>& r); 
template<class Y> // assign from 


shared_ptr& operator=(shared_ptr<Y> const& r); // any compatible 
template<class Y> // shared_ptr or 
shared_ptr& operator=(auto_ptr<Y>& r); // auto_ptr 


T 


除了 generalized copy constructor GZz2i(b# Mie) , PMAR constructors (478 
数 ) Bz explicit (2) 的 。 这 就 意味 着 从 shared_ptr 的 一 种 类 型 到 另 一 种 的 implicit 
conversion ( 隐 式 转换 ) 是 被 允许 的 ， 但 是 从 一 个 built-in pointer (内 建 指针 ) 或 其 smart 
pointer type (智能 指针 类 型 ) 的 implicit conversion ( 隐 式 转换 ) 是 不 被 许可 的 。 (explicit 
conversion ( 显 式 转换 ) 一 例如， 经 由 一 个 cast (强制 转型 ) 一 一 还 是 可 以 的 。) 同样 引起 
注意 的 是 auto_ptrs 被 传送 给 tr1::shared_ptr 的 constructors (74382321) 和 assignment 
Operators (赋值 操作 符 ) 的 方式 没有 被 声明 为 const， 于 此 对 照 的 是 tr1::shared_ptrs 和 
tr1::weak_ptrs 的 被 传送 的 方式 。 这 是 auto_ptrs 被 复制 时 需要 独一无二 的 被 改变 的 事实 的 一 
个 必然 结果 (参见 Item 13) 。 


member function templates (ak A HBV) 是 一 个 极 好 的 未 西 ， 但 是 它们 没有 改变 这 个 语 
言 的 基本 规则 。ltem 5 阐述 的 编译 器 可 以 产生 的 四 个 member functions (AK A NR) 其 中 两 
个 是 copy constructor ( 找 贝 构造 画 数 ) 和 copy assignment operator (拷贝 赋值 运算 符 ) 。 
tr1::shared_ptr 声明 了 一 个 generalized copy constructor (ZUL n png) ， 而 且 很 明 
显 ， 当 类 型 T 和 YY 相同 时 ，generalized copy constructor (ZEUL n ISHN) 就 能 被 实 
例 化 而 成 为 "normal" copy constructor (“AU's A 构造 画 数 ) 。 那 么 ， 当 一 人 

tr1::shared_ptr object 从 另 一 个 相同 类 型 的 tr1::shared_ptr object 构造 时 ， 编 译 器 是 为 
tr1::shared_ptr 生成 一 个 copy constructor (R41 HM) ， 还 是 实例 化 generalized copy 
constructor template ( 泛 型 化 拷贝 构造 画 数 模板 ) ? 


就 像 我 说 过 的 ，member templates (成 员 模 板 ) 不 改变 语言 规则 ， 而 且 规则 uuu 
copy constructor G42 Wis HM) 是 必需 的 而 你 没有 声明 ， 将 为 你 自动 生成 一 个 。 在 一 个 
class 中 声明 一 个 generalized copy constructor ( 泛 型 化 拷贝 构造 画 数 ) i member 
template (成 员 模 板 ) ) 不 会 阻止 编译 器 生成 它们 自己 的 copy constructor (#8 n His BR) 

( 非 模板 的 ) ， 所 以 如 果 你 要 全 面 支配 copy construction (拷贝 构造 ) ， 你 必须 既 声明 一 
generalized copy constructor 〈 泛 型 化 拷贝 构造 画 数 ) 又 声明 一 个 "normal" apy 
constructor 〈“ 常 规 " 拷 贝 构造 范 数 ) 。 这 同样 适用 于 assignment (赋值 ) 。 这 是 从 
tr1::shared_ptr 的 定义 中 摘录 的 一 段 ， 可 以 作为 例子 


template<class T> class shared_ptr { 


public: 
shared_ptr(shared_ptr const& r); // 
template<class Y> // 
shared_ptr(shared_ptr<Y> const& r); // 
shared_ptr& operator=(shared_ptr const& r); // 
template<class Y> // 


shared_ptr& operator=(shared_ptr<Y> const& r); // 


a 


Things to Remember 


copy constructor 


generalized 
copy constructor 


copy assignment 


generalized 
copy assignment 


e 使 用 member function templates (PX A BURR) 生成 接受 所 有 兼容 类 型 的 函数 。 


。 如 果 你 为 generalized copy construction 〈 泛 型 化 拷贝 构造 ) 或 generalized 
assignment ( 泛 型 化 赋值 ) 声明 了 member templates (成 员 模 板 ) ， 你 依然 需要 声明 
normal copy constructor 〈 常 规 拷 贝 构造 本 数 ) 和 copy assignment operator (拷贝 赋值 


运算 符 ) 。 


Item 46: 需要 type conversions (类 型 转换 ) 时 在 
elates (模板 ) 内 定义 non-member 
functions (3FA ñ NA) 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


Item 24 阐述 了 为 什么 只 有 non-member functions (JERK ABA) 适合 于 应 用 到 所 有 
arguments ( 实 参 ) 的 implicit type conversions ( 隐 式 类 型 转换 ) ， 而 且 它 还 作为 一 个 示例 使 
用 了 一 个 Rational class 的 operator function。 我 建议 你 在 继续 下 去 之 前 先 熟悉 那个 示例 ， 
因为 这 个 Item 进行 了 针对 Item 24 中 的 示例 的 一 个 表面 上 的 无 伤 大 雅 的 更 改 (模板 化 
Rational 和 operator) 的 扩展 讨论 : 


template<typename T> 
class Rational { 


public: 
Rational(const T& numerator = 0, // see Item 20 for why params 
const T& denominator = 1); // are now passed by reference 
const T numerator() const; // see Item 28 for why return 
const T denominator() const; // “values are still passed by value, 
ear // Item 3 for why they're const 
}; 


template<typename T> 

const Rational<T> operator*(const Rational<T>& lhs, 
const Rational<T>& rhs) 

{ead 


就 像 在 Item 24 中 ， 我 想 要 支持 mixed-mode arithmetic (混合 模式 运算 ) ， 所 以 我 们 要 让 下 
面 这 些 代 码 能 够 编译 。 我 们 指望 它 能 ， 因 为 我 们 使 用 了 和 ltem 24 中 可 以 工作 的 代码 相同 的 代 
码 。 仅 有 的 区 别 是 Rational 和 operator* 现在 是 templates (模板 ) 


Rational<int> oneHalf(1, 2); // this example is from Item 24, 
// except Rational is now a template 


Rational<int> result = oneHalf * 2; // error! won't compile 


编译 失败 的 事实 暗示 对 于 模板 化 Rational 来 说 ， 有 某 些 东 西 和 non-template ( 非 模 板 ) 版 本 
不 同 ， 而 且 确 实 存 在 。 在 ltem 24 中 ， 编 译 器 知道 我 们 想 要 调用 什么 函数 (取得 两 个 
Rationals 的 operator*) ， 但 是 在 这 里 ， 编 译 器 不 知道 我 们 想 要 调用 哪个 函数 。 作 为 替代 ， 
们 试图 figure out GEM) 要 从 名 为 operator 的 template (模板 ) 中 实例 化 出 (也 就 是 创 


E) 什么 画 数 。 它 们 知道 它们 假定 实例 化 出 的 某 个 名 为 operator 的 函数 取得 两 个 
Rational<T> 类 型 的 参数 ， 但 是 为 了 做 这 个 实例 化 ， 它 们 必须 figure out (推断 ) T 是 什么 。 
问题 在 于 ， 它 们 做 不 到 。 


在 推演 十 的 尝试 中 ， 它 们 会 察看 被 传 入 operator 的 调用 的 arguments (XB) 的 类 型 。 在 当 
前 情况 下 ， 类 型 为 Rational<int> (oneHalf 的 类 型 ) 和 int (2 的 类 型 ) 。 每 一 个 参数 被 分 别 


使 用 oneHalf 的 推演 很 简单 。operator 的 第 一 个 parameter (#2) 被 声明 为 Rational<T> 
类 型 ， 而 传人 operator 的 第 一 个 argument ( 实 参 ) (oneHalf) 是 Rational<int> 类 型 ， 所 以 下 
一 定 是 int。 不 幸 的 是 ， 对 其 它 参 数 的 推演 没 那么 简单 。operator 的 第 二 个 parameter (H 
参 ) 被 声明 为 Rational<T> 类 型 ， 但 是 传人 operator 的 第 二 个 argument (LB) (2) 的 int 
类 型 。 在 这 种 情况 下 ， 让 编译 器 如 何 figure out (HEMT) T 是 什么 呢 ? 你 可 能 期 望 它们 会 使 用 
Rational<int> 的 non-explicit constructor (JE E RERO 将 2 转换 成 一 个 

Rational<int>， 这 样 就 使 它们 推演 出 T 是 int， 但 是 它们 不 这 样 做 。 它 们 不 这 样 做 是 因为 在 
template argument deduction (模板 实 参 推演 ) 过 程 中 从 不 考虑 implicit type conversion 
functions 〈 降 式 类 型 转换 男 数 ) 。 从 不 。 这 样 的 转换 可 用 于 画 数 调用 过 程 ， 这 没 错 ， 但 是 在 
你 可 以 调用 一 个 画 数 之 前 ， 你 必须 知道 哪个 函数 存在 。 为 了 知道 这 些 ， 你 必须 为 相关 的 
function templates (HURR) 推演 出 parameter types (参数 类 型 ) (以 便 你 可 以 实例 化 出 
合适 的 函数 ) 。 但 是 在 template argument deduction (模板 实 参 推演 ) 过 程 中 不 考虑 经 由 
constructor (#43E2%) 调用 的 implicit type conversion ( 隐 式 类 型 转换 ) > Item 24 不 包括 
templates (模板 ) ， 所 以 template argument deduction (模板 实 参 推演 ) 不 是 一 个 问题 ， 现 
在 我 们 在 C++ 的 template 部 分 (参见 Item 1) ， 这 是 主要 问题 。 


在 一 个 template class (模板 类 ) 中 的 一 个 friend declaration 〈 友 元 声明 ) 可 以 指 涉 到 一 个 特 
定 的 函数 ， 我 们 可 以 利用 这 一 事实 为 受到 template argument deduction (模板 实 参 推演 ) Pk 
战 的 编译 器 解围 。 这 就 意味 着 class Rational<T> 可 以 为 Rational<T> 声明 作为 一 个 friend 
function ( 友 元 函数 ) 的 operator*。class templates (类 模板 ) 不 依靠 template argument 
deduction (模板 实 参 推演 ) (这 个 过 程 仅 适用 于 function templates (NEAR) ) ， 所 以 T 
在 class Rational<T> 被 实例 化 时 总 是 已 知 的 。 通 过 将 适当 的 operator* 声明 为 Rational<T> 
class 的 一 个 friend (Ait) 使 其 变 得 容易 : 


template<typename T> 
class Rational { 


public: 
friend // declare operator* 
const Rational operator*(const Rational& lhs, // function (see 
const Rational& rhs); // below for details) 
J; 
template<typename T> // define operator* 


const Rational<T> operator*(const Rational<T>& lhs, // functions 
const Rational<T>& rhs) 
iE secre ot 


现在 我 们 对 operator 的 混合 模式 调用 可 以 编译 了 ， 因 为 当 object oneHalf 被 声明 为 
Rational<int> 类 型 时 ，class Rational<int> 被 实例 化 ， 而 作为 这 一 过 程 的 一 部 分 ， 取 得 
Rational<int> parameters ( 形 参 ) 的 friend function ( 友 元 函数 ) operato 被 自动 声明 。 作 
为 已 声明 function (H2) (并 非 一 个 function template (HAAR) ) ， 在 调用 它 的 时 候 编 
译 器 可 以 使 用 implicit conversion functions (RHR (ŒA Rational 的 non-explicit 
constructor (JE RADERNA) ) ， 而 这 就 是 它们 如 何 使 得 混合 模式 调用 成 功 的 。 


唉 ， 在 这 里 的 上 下 文中 ，“ 成 功 " 是 一 个 可 笑 的 词 ， 因 为 尽管 代码 可 以 编译 ， 但 是 不 能 连接 。 但 
是 我 们 过 一 会 儿 再 处 理 它 ， 首 先 我 想 讨 论 一 下 用 于 在 Rational 内 声明 operator* 的 语法 。 


在 一 个 class template (类 模板 ) ABB, template (模板 ) 的 名 字 可 以 被 用 做 template ( 模 
板 ) 和 它 的 parameters (参数 ) 的 缩写 ， 所 以 ， 在 Rational<T> 内 部 ， 我 们 可 以 只 写 

Rational {t# Rational<T>。 在 本 例 中 这 只 为 我 们 节省 了 几 个 字符 ， 但 是 当 有 多 个 参数 或 有 更 
长 的 参数 名 时 ， 这 既 能 节省 击 键 次 数 又 能 使 最 终 的 代码 显得 更 清晰 。 我 把 这 一 点 提前 ， 是 因 
为 operator 被 声明 为 取得 并 返回 Rationals， 而 不 是 Rational<T>s。 它 就 像 如 下 这 样 声 明 
operator* 一 样 合 法 : 


template<typename T> 
class Rational { 
public: 


friend 
const Rational<T> operator*(const Rational<T>& lhs, 
const Rational<T>& rhs); 


ee 


然而 ， 使 用 缩写 形式 更 简单 (而 且 更 常用 ) 。 


现在 返回 到 连接 问题 。 混 合 模式 代码 编译 ， 因 为 编译 器 知道 我 们 想 要 调用 一 个 特定 的 函数 
(取得 一 个 Rational<int> 和 一 个 Rational<int> 的 operator*) ， 但 是 那个 函数 只 是 在 

Rational 内 部 declared (被 声明 ) ， 而 没有 在 此 久 defined (WEL) 。 我 们 打算 让 class 之 
外 的 operator template (模板 ) 提供 这 个 定义 ， 但 是 这 种 方法 不 能 工作 。 如 果 我 们 自己 声明 
AKA 〈 这 就 是 我 们 在 Rational template (模板 ) 内 部 所 做 的 事 ) ， 我 们 就 有 责任 定义 这 
个 画 数 。 当 前 情况 是 ， 我 们 没有 提供 定义 ， 这 也 就 是 连接 器 为 什么 不 能 找到 它 。 


让 它 能 工作 的 最 简单 的 方法 或 许 就 是 将 operator 的 本 体 合 并 到 它 的 declaration (EX) 中 : 


template<typename T> 
class Rational { 
public: 


friend const Rational operator*(const Rational& lhs, const Rational& rhs) 


{ 
return Rational(lhs.numerator() * rhs.numerator(), // same impl 
lhs.denominator() * rhs.denominator()); // as in 
} // Item 24 


}; 


确实 ， 这 样 就 可 以 符合 预期 地 工作 : 对 operator 的 混合 模式 调用 现在 可 以 编译 ， 连 接 ， 并 运 
íT. AF ! 


关于 此 技术 的 一 个 有 趣 的 观察 结论 是 friendship 的 使 用 对 于 访问 class 的 non-public 

parts ( 非 公 有 构件 ) 的 需求 并 没有 起 到 什么 作用 。 为 了 让 所 有 arguments (XB) 的 type 

conversions (类 型 转换 ) 成 为 可 能 ， 我 们 需要 一 个 non-member function (JER A ER) 
(Item 24 依然 适用 ) ; 而 为 了 能 自动 实例 化 出 适当 的 函数 ， 我 们 需要 在 class 内 部 声明 这 个 

函数 。 在 一 个 class 内 部 声明 一 个 non-member function (JERK ABA) 的 唯一 方法 就 是 把 它 

做 成 一 个 friend (IT) 。 那 么 这 就 是 我 们 做 的 。 反 传统 吗 ? 是 的 。 有 效 吗 ? SRE. 


就 像 Item 30 阅 述 的 ， 定 义 在 一 个 class 内 部 的 函数 被 隐 式 地 声明 为 inline (A) ， 而 这 也 
包括 像 operator* 这 样 的 friend functions 〈 友 元 函数 ) 。 你 可 以 让 operator 不 做 什么 事情 ， 
只 是 调用 一 个 定义 在 这 个 class 之 外 的 helper function (BER) ， 从 而 让 这 样 的 inline 
declarations (AFAR) 的 影响 最 小 化 。 在 本 Item 的 这 个 示例 中 ， 没 有 特别 指出 这 样 做 ， 
为 operator* 已 经 可 以 实现 为 一 个 one-line function (HWA) ， 但 是 对 于 更 复杂 的 画 数 
体 ， 这 样 做 也 许 是 合适 的 。"have the friend call a helper" (“让 友 元 调用 辅助 函数 ”) 的 方法 还 
是 值得 注意 一 下 的 。 


Rational 是 一 个 template (模板 ) 的 事实 意味 着 那个 helper function (辅助 画 数 ) 通常 也 是 一 
个 template (模板 ) ， 所 以 典型 情况 下 在 头 文件 中 定义 Rational 的 代码 看 起 来 大 致 如 下 : 


template<typename T> class Rational; // declare 

// Rational 

// template 
template<typename T> // declare 
const Rational<T> doMultiply(const Rational<T>& lhs, // helper 

const Rational<T>& rhs); // template 

template<typename T> 
class Rational { 
public: 


friend 
const Rational<T> operator*(const Rational<T>& lhs, 
const Rational<T>& rhs) // Have friend 
{ return doMultiply(lhs, rhs); } // call helper 


}; 


多 数 编译 器 基本 上 会 强迫 你 把 所 有 的 template definitions (模板 定义 ) 都 放 在 头 文 件 中 ， 所 以 
你 可 能 同样 需要 在 你 的 头 文 件 中 定义 doMultiply。 (RR Item 30 阐述 的 ， 这 样 的 
templates (模板 ) 不 需要 inline (A) 。) 可 能 看 起 来 就 像 这 样 : 


emplate<typename T> // define 
const Rational<T> doMultiply(const Rational<T>& lhs, // helper 
const Rational<T>& rhs) // template in 


// header file, 
return Rational<T>(lhs.numerator() * rhs.numerator(), // if necessary 
lhs.denominator() * rhs.denominator()); 


当然 ， 作 为 一 个 template (模板 ) , doMultiply 不 支持 混合 模式 乘法 ， 但 是 它 不 需要 。 它 只 被 

operator 调用， 而 operator 支持 混合 模式 运算 ! 本质 上 ，function operator 支持 为 了 确保 

被 相 乘 的 是 两 个 Rational objects 而 必需 的 各 种 type conversions (类 型 转换 ) ， 然 后 它 将 这 

两 个 objects 传递 给 一 个 doMultiply template (模板 ) 的 适当 的 实例 化 来 做 实际 的 乘法 。 配 合 

行动 ， 不 是 吗 ? 

Things to Remember 

。 在 写 一 个 class template (类 模板 ) ， 而 这 个 class template (类 模板 ) He THE 

数 ， 这 些 函 数 指 涉 到 支持 所 有 parameters (参数 ) 的 implicit type conversions ( 隐 式 类 
型 转换 ) 的 template (模板 ) 的 时 候 ， 把 这 些 画 数 定义 为 class template (类 模板 ) 内 部 
BY friends (RI) 。 


Item 47: 为 类 型 信息 使 用 traits classes (特征 
类 ) 

KR 

作者 : Scott Meyers 

3% : fatalerror99 (iTePub's Nirvana) 

发 布 : http://blog.csdn.net/fatalerror99/ 


STL 主要 是 由 containers (容器 ) , iterators (迭代 器 ) 和 algorithms (算法 ) 的 
templates (模板 ) 构成 的 ， 但 是 也 有 几 个 utility templates (实用 模板 ) 。 其 中 一 个 被 称 为 
advance, advance 将 一 个 指定 的 iterator (迭代 器 ) 移动 一 个 指定 的 距离 : 


template<typename IterT, typename DistT> // move iter d units 
void advance(IterT& iter, DistT d); // forward; if d < 0, 
// move iter backward 


在 概念 上 ，advance 仅仅 是 在 做 iter += d， 但 是 advance 不 能 这 样 实现 ， 因 为 只 有 random 
access iterators (随机 访问 迭代 器 ) 支持 += operation。 不 够 强力 的 iterator (迭代 器 ) 类 型 
不 得 不 通过 反复 利用 ++ 或 -- d 次 来 实现 advance. 


吧 ， 你 不 记得 STL iterator categories GRAP X) 了 吗 ? 没 问题 ， 我 们 这 就 做 一 个 简单 回 
顾 。 对 应 于 它们 所 支持 的 操作 ， 共 有 五 种 iterators (迭代 器 ) 。input iterators (输入 迭代 
as) 只 能 向 前 移动 ， 每 次 只 能 移动 一 步 ， 只 能 读 它们 指向 的 东西 ， 而 且 只 能 读 一 次 。 它 们 以 
一 个 输入 文件 中 的 read pointer 〈 读 指针 ) 为 原型 ; C++ 库 中 的 istream_iterators 就 是 这 一 种 
类 的 典型 代表 。output iterators (输出 迭代 器 ) 与 此 类 似 ， 只 不 过 用 于 输出 : 它们 只 能 向 前 移 
动 ， 每 次 只 能 移动 一 步 ， 只 能 宇 它 们 指向 的 未 西 ， 而 且 只 能 写 一 次 。 它 们 以 一 个 输出 文件 中 
的 write pointer ( 写 指 针 ) 为 原型 ; ostream_iterators 是 这 一 种 类 的 典型 代表 。 这 是 两 个 最 不 
强力 的 iterator categories (迭代 器 种 类 ) 。 因 为 input (输入 ) 和 output iterators (输出 迭代 
as) 只 能 向 前 移动 而 且 只 能 读 或 者 写 它 们 指向 的 地 方 最 多 一 次 ， 它 们 只 适合 one-pass 运算 。 


一 个 更 强力 一 些 的 iterator category (迭代 器 种 类 ) 是 forward iterators (前 向 迭代 器 ) 。 这 种 
iterators (和 迭代 器 ) 能 做 input GAA) 和 output iterators (输出 迭代 器 ) 可 以 做 到 的 每 一 件 
事情 ， 再 加 上 它们 可 以 读 或 者 写 它 们 指向 的 东西 一 次 以 上 。 这 就 使 得 它们 可 用 于 multi-pass 
运算 。STL 没有 提供 singly linked list ( 单 向 链表 ) ， 但 某 些 库 提供 了 (通常 被 称 为 slist) , 
而 这 种 containers (容器 ) 的 iterators GRA) 就 是 forward iterators (前 向 迭代 器 ) 。 
TR1 的 hashed containers ( 哈 希 容器 ) (参见 Item 54) 的 iterators (迭代 器 ) 也 可 以 属于 
forward category (前 向 迭代 器 ) o 


bidirectional iterators (双向 迭代 器 ) 为 forward iterators (前 向 迭代 器 ) 加 上 了 和 向 前 一 样 的 
向 后 移动 的 能 力 。STL 的 list 的 iterators ORRA) 属于 这 一 种 类 ，set，multiset，map 和 
multimap 的 iterators (迭代 器 ) 也 一 样 。 


最 强力 的 iterator category (迭代 器 种 类 ) 是 random access iterators (随机 访问 迭代 器 ) 。 
这 种 iterators (迭代 器 ) 为 bidirectional iterators (双向 迭代 器 ) 加 上 了 "iterator 
arithmetic" (“迭代 器 运算 ”) 的 能 力 ， 也 就 是 说 ， 在 常量 时 间 里 向 前 或 者 向 后 跳 转 一 个 任意 的 
距离 。 这 样 的 运算 类 似 于 指针 运算 ， 这 并 不 会 让 人 感到 惊讶 ， 因 为 random access 

iterators (随机 访问 迭代 器 ) 就 是 以 built-in pointers (内 建 指针 ) 为 原型 的 ， 而 built-in 
pointers (内 建 指针 ) 可 以 和 random access iterators (随机 访问 迭代 器 ) 有 同样 的 行为 。 
vector, deque 和 string 的 iterators (人 迭代 器 ) Æ random access iterators (随机 访问 迭代 
器 ) 。 

对 于 五 种 iterator categories (迭代 器 种 类 ) 中 的 每 一 种 ，C++ 都 有 一 个 用 于 识别 它 的 "tag 
struct" (“标签 结构 体 ”) 在 标准 库 中 : 


struct input_iterator_tag {}; 

struct output_iterator_tag {}; 

struct forward_iterator_tag: public input_iterator_tag {}; 

struct bidirectional_iterator_tag: public forward_iterator_tag {}; 


struct random_access_iterator_tag: public bidirectional_iterator_tag {}; 


这 些 结构 体 之 间 的 inheritance relationships (继承 关系 ) 是 正当 的 is-a 关系 (BR Item 
32) : 所 有 的 forward iterators (前 向 迭代 器 ) 也 是 input iterators (输入 迭代 器 ) ， 等 等 ， 这 
都 是 成 立 的 。 我 们 不 久 就 会 看 到 这 个 inheritance (继承 ) 的 功用 。 


但 是 返回 到 advance. 对 于 不 同 的 iterator (迭代 器 ) 能 力 ， 实 现 advance 的 一 个 方法 是 使 用 
反复 增加 或 减少 iterator (迭代 器 ) 的 循环 的 lowest-common-denominator (最 小 共通 特性 ) 

策略 。 然 而 ， 这 个 方法 要 花费 linear time (线性 时 间 ) 。random access iterators (随机 访问 
迭代 器 ) 支持 constant-time iterator arithmetic (常量 时 间 和 迭代 器 运算 ) ， 当 它 出 现 的 时 候 我 
们 最 好 能 利用 这 种 能 力 。 


我 们 真正 想 做 的 就 是 大 致 像 这 样 实现 advance : 


template<typename IterT, typename DistT> 
void advance(IterT& iter, DistT d) 


if (iter is a random access iterator) { 


iter += d; // use iterator arithmetic 
} // for random access iters 
else { 

if (d >= 0) { while (d--) ++iter; } // use iterative calls to 

else { while (d++) --iter; } // ++ or -- for other 
} // iterator categories 


} 


这 就 需要 能 够 确定 iter 是 否 是 一 个 random access iterators (随机 访问 迭代 器 ) ， 依 次 下 来 ， 
就 需要 知道 它 的 类 型 ，lterT， 是 否 是 一 个 random access iterators (随机 访问 迭代 器 ) 类 
型 。 换 句 话 说 ， 我 们 需要 得 到 关于 一 个 类 型 的 某 些 信息 。 这 就 是 traits 让 你 做 到 的 : 它们 允许 
你 在 编译 过 程 中 得 到 关于 一 个 类 型 的 信息 。 


traits 不 是 C++ 中 的 一 个 关键 字 或 预定 义 结构 ; 它们 是 一 项 技术 和 C++ 程序 员 遵 守 的 惯例 。 
建立 这 项 技术 的 要 求 之 一 是 它 在 built-in types (内 建 类 型 ) 上 必须 和 在 user-defined 

types (用 户 定义 类 型 ) 上 一 样 有 效 。 例 如 ， 如 果 advance 被 一 个 指针 〈 辟 如 一 个 const 
char*) 和 一 个 int 调用 ，advance 必须 有 效 ， 但 是 这 就 意味 着 traits 技术 必须 适用 于 像 指 针 这 
样 的 built-in types (内 建 类 型 ) 。 


traits 对 built-in types (内 建 类 型 ) 必须 有 效 的 事实 意味 着 将 信息 棒 入 到 类 型 内 部 是 不 可 以 
的 ， 因 为 没有 办 法 将 信息 嵌入 指针 内 部 。 那 么 ， 一 个 类 型 的 traits 信息 ， 必 须 在 类 型 外 部 。 标 
准 的 方法 是 将 它 放 到 template (模板 ) 以 及 这 个 template (模板 ) 的 一 个 或 更 多 的 
specializations ( 特 化 ) 中 。 对 于 iterators CIRA) ， 标 准 库 中 template (模板 ) 被 称 为 
iterator traits : 


template<typename IterT> // template for information about 
struct iterator_traits; // iterator types 


就 像 你 能 看 到 的 ，iterator traits 是 一 个 struct (结构 体 ) 。 根 据 惯 例 ，traits 总 是 被 实现 为 
struct (结构 体 ) 。 另 一 个 惯例 就 是 用 来 实现 traits 的 structs (结构 体 ) Li traits classes (这 
可 不 是 我 捏造 的 ) 闻名 。 


iterator traits 的 工作 方法 是 对 于 每 一 个 lterT 类 型 ， 在 struct (444414) iterator_traits<IterT> 
中 声明 一 个 名 为 iterator_category 的 typedef。 这 个 typedef 被 看 成 是 lterT 的 iterator 
category (迭代 器 种 类 ) 。 


iterator_traits 通过 两 部 分 实现 这 一 点 。 首 先 ， 它 强制 要 求 任何 user-defined iterator (FA > EŒ 
LERE) 类 型 必须 包含 一 个 名 为 iterator_category HEE typedef 用 以 识别 适合 的 tag 
struct (标签 结构 体 ) 。 例 如 ，deque 的 iterators (迭代 器 ) 是 随机 访问 的 ， 所 以 一 个 deque 
iterators 的 class 看 起 来 就 像 这 样 : 


template < ... > // template params elided 
class deque { 
public: 
class iterator { 
public: 
typedef random_access_iterator_tag iterator_category; 


}; 
T 


然而 ，list 的 iterators CERA) 是 双向 的 ， 所 以 它们 是 这 样 做 的 : 


template < ... > 
class list { 
public: 
class iterator { 
public: 
typedef bidirectional_iterator_tag iterator_category; 


fa 
or 


iterator_traits 仅仅 是 简单 地 模仿 了 iterator class WERE typedef : 


// the iterator_category for type IterT is whatever IterT says it is; 
// see Item 42 for info on the use of "typedef typename" 
template<typename IterT> 
struct iterator_traits { 

typedef typename IterT::iterator_category iterator_category; 


}; 


这 样 对 于 user-defined types (用 户 定义 类 型 ) 能 很 好 地 运转 。 但 是 对 于 本 身 是 pointers (48 
$+) 的 iterators GANZ) 根本 不 起 作用 ， 因 为 不 存在 类 似 于 带 有 一 个 找 套 typedef 的 指针 的 
东西 。iterator_traits 实现 的 第 二 个 部 分 义理 本 身 是 pointers (指针 ) 的 iterators GERZ) 。 


为 了 支持 这 样 的 iterators (迭代 器 ) , iterator_traits 为 pointer types (指针 类 型 ) 提供 了 一 
个 partial template specialization (部 分 模板 特 化 ) . pointers 的 行为 类 似 random access 
iterators (随机 访问 迭代 器 ) ， 所 以 这 就 是 iterator traits 为 它们 指定 的 种 类 : 


template<typename IterT> // partial template specialization 
struct iterator_traits<IterT*> // for built-in pointer types 


typedef random_access_iterator_tag iterator_category; 


ae 


到 此 为 止 ， 你 了 解 了 如 何 设计 和 实现 一 个 traits class : 


e。 识别 你 想 让 它 可 用 的 关于 类 型 的 一 些 信息 (例如 ， 对 于 iterators (迭代 器 ) Kit, Mee 
们 的 iterator category (和 迭代 器 种 类 ) ) 。 


。 选择 一 个 名 字 标 识 这 个 信息 (例如 ，iterator_category) 。 


。 提供 一 个 template (模板 ) 和 一 系列 specializations ( 特 化 ) (例如 ，iterator_traits) , 
它们 包含 你 要 支持 的 类 型 的 信息 。 


给 出 了 iterator_traits 一 一 实际 上 是 std::iterator traits， 因 为 它 是 C++ 标准 库 的 一 部 分 一 一 我 
们 就 可 以 改善 我 们 的 advance 伪 代 码 : 


template<typename IterT, typename DistT> 
void advance(IterT& iter, DistT d) 


if (typeid(typename std::iterator_traits<IterT>::iterator_category) == 
typeid(std::random_access_iterator_tag) ) 


这 个 虽然 看 起 来 有 点 希望 ， 但 它 不 是 我 们 想 要 的 。 在 某 种 状态 下 ， 它 会 导致 编译 问题 ， 但 是 

我 们 到 Item 48 再 来 研究 它 ， 现 在 ， 有 一 个 更 基础 的 问题 要 讨论 。lterT 的 类 型 在 编译 期 间 是 
已 知 的 ， 所 以 iterator traits<lterT>::iterator_category 可 以 在 编译 期 间 被 确定 。 但 是 if 语句 还 
是 要 到 运行 时 才能 被 求 值 。 为 什么 要 到 运行 时 才 做 我 们 在 编译 期 间 就 能 做 的 事情 呢 ? 它 浪费 

了 时 间 (严格 意义 上 的 ) ， 而 且 使 我 们 的 执行 码 膨胀 。 


我 们 真正 想 要 的 是 一 个 针对 在 编译 期 间 被 鉴别 的 类 型 的 conditional construct (条 件 结构 ) 
(也 就 是 说 ， 一 个 if...else 语句 ) 。 碰 巧 的 是 ，C++ 已 经 有 了 一 个 得 到 这 种 行为 的 方法 。 它 被 
称 为 overloading (BR) 。 


HERECKA EN, (RAAB overloads (2H) 指定 不 同 的 parameter types (HE 
类 型 ) 。 当 你 调用 f 时 ， 编 译 器 会 根据 被 传递 的 arguments (XB) 挑 出 最 佳 的 

overload ( 重 载 ) 。 基 本 上 ， 编 译 器 会 说 : “如果 这 个 overload (E8) 与 被 传递 的 东西 是 最 
佳 匹配 的 话 ， 就 调用 这 个 f; 如 果 另 一 个 overload (BHR) 是 最 佳 匹配 ， 就 调用 它 ; 如 果 第 三 
个 overload (BH) 是 最 佳 的 ， 就 调用 它 "等 等 。 看 到 了 吗 ? 一 个 针对 类 型 的 compile-time 
conditional construct (编译 时 条 件 结 构 ) 。 为 了 让 advance 拥有 我 们 想 要 的 行为 方式 ， 我 们 
必须 要 做 的 全 部 就 是 创建 一 个 包含 advance 的 “内 容 " 的 重 载 画 数 的 多 个 版 本 (此 处 原文 有 
误 ， 根 据 作 者 网 站 勘误 修改 一 一 译 者 注 ) ， 声 明 它 们 取得 不 同 iterator_category object 的 类 
W, RAR AWB AS doAdvance : 


template<typename IterT, typename DistT> // use this impl for 

void doAdvance(IterT& iter, DistT d, // random access 
std: :random_access_iterator_tag) // iterators 

{ 

iter += d; 

} 

template<typename IterT, typename DistT> // use this impl for 

void doAdvance(IterT& iter, DistT d, // bidirectional 
std: :bidirectional_iterator_tag) // iterators 


if (d >= 0) { while (d--) ++iter; } 
else { while (d++) --iter; } 


} 
template<typename IterT, typename DistT> // use this impl for 
void doAdvance(IterT& iter, DistT d, // input iterators 


std: :input_iterator_tag) 


if (d<0) { 
throw std::out_of_range("Negative distance"); // see below 


while (d--) ++iter; 


% forward_iterator_tag 从 input_iterator_tag 继承 而 来 ， 针 对 input_iterator_tag 的 
doAdvance 版 本 也 将 处 理 forward iterators (前 向 迭代 器 ) 。 这 就 是 在 不 同 的 iterator_tag 
structs 之 间 继 承 的 动机 。 (实际 上 ， 这 是 所 有 public inheritance (公有 继承 ) 的 动机 的 一 
分 : 使 针对 base class types ( 基 类 类 型 ) 写 的 代码 也 能 对 derived class types (派生 类 类 
型 ) 起 作用 。) 


advance 的 规范 对 于 random access (随机 访问 ) 和 bidirectional iterators (双向 迭代 器 ) fù 
许 正 的 和 负 的 移动 距离 ， 但 是 如 果 你 试图 移动 一 个 forward (前 向 ) SX input iterator GAA E 
Kes) 一 个 负 的 距离 ， 则 和 We ee 设 d 是 非 负 的 ， 因 
而 如 果 一 个 负 的 距离 被 传人 和信， 则 进入 一 个 直到 计数 降 为 雾 的 非常 长 的 循环 。 在 上 面 的 代码 
中 ， 我 展示 了 改 为 一 个 异常 被 抛 出 。 ; cia oe 未 定义 行为 的 诅咒 是 : 你 无 法 
预知 会 发 生 什 么 。 


给 出 针对 doAdvance 的 各 种 重 载 ，advance 需要 做 的 全 部 就 是 调用 它们 ， 传 递 一 个 适当 的 
iterator category Ga asthe) 类 型 的 额外 object 以 便 编 译 器 利用 overloading 
resolution 〈 重 载 解析 ) 来 调用 正确 的 实现 : 


template<typename IterT, typename DistT> 
void advance(IterT& iter, DistT d) 


doAdvance( // call the version 
iter, d, // of doAdvance 
typename // that is 
std: :iterator_traits<IterT>: :iterator_category() // appropriate for 
Ne / iter's iterator 
} 


我 们 现在 能 够 概述 如 何 使 用 一 个 traits class 了 : 


。 创建 一 套 重 载 的 "worker" functions (2) 或 者 function templates (WAR) (fl) 
如 ，doAdvance) ， 它 们 在 一 个 traits parameter ( 形 参 ) 上 不 同 。 与 传递 的 traits 信息 
一 致 地 实现 每 一 个 图 数 。 


。 创建 一 个 "master" function (He) ER function templates (HAE) (FAN, 
advance) 调用 这 些 workers， 传 递 通 过 一 个 traits class 提供 的 信息 。 


traits 广泛 地 用 于 标准 库 中 。 有 iterator traits， 当 然 ， 再 加 上 iterator_category， 提 供 了 关于 
iterators (迭代 器 ) 的 四 块 其 它 信息 (其 中 最 常用 的 是 value_type — ltem 42 展示 了 使 用 它 
的 示例 ) 。 还 有 char traits 持 有 关于 character types (字符 类 型 ) 的 信息 ， 还 有 
numeric_limits 提供 关于 numeric types (数值 类 型 ) 的 信息 ， 例 如 ， 可 表示 值 的 最 小 值 和 最 
大 值 ， 等 等 。 (名 字 numeric_limits 伟人 有 些 奇怪 ， 因 为 关于 traits classes 更 常用 的 惯例 是 
以 "traits" 结束 ， 但 是 它 就 是 被 叫做 numeric_ limits， 所 以 numeric_limits 就 是 我 们 用 的 名 

Fo ) 


TR1 (参见 Item 54) 引入 了 一 大 批 新 的 traits classes 提供 关于 类 型 的 信息 ， 包 括 
is_fundamental<T> (T 是 否 是 一 个 built-in type (内 建 类 型 ) ) ，is_array<T> (T 是 否 是 一 
个 array type (数组 类 型 ) ) ， 以 及 is_base_of<T1, T2> (T1 是 否 和 T2 相同 或 者 是 T2 的 一 


“base class ( 基 类 ) ) 。 合 计 起 来 ，TR1 在 标准 C++ 中 加 入 了 超过 50 个 traits classes. 
Things to Remember 


e traits classes 使 关于 类 型 的 信息 在 编译 期 间 可 用 。 它 们 使 用 templates (模板 ) 和 
template specializations (模板 特 化 ) 实现 。 


e 结合 overloading 〈 重 载 ) traits classes 使 得 执行 编译 期 类 型 if...else 检验 成 为 可 能 。 


Item 48: 感受 template metaprogramming (模板 
元 编程 ) 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


template metaprogramming (TMP) (模板 元 编程 》 是 写 template-based (基于 模板 ) 的 运行 
于 编译 期 间 的 C++ 程序 的 过 程 。 考 虑 一 下 : 一 个 template metaprogram (模板 元 程序 ) 是 用 
C++ 写 的 运行 于 C++ 编译 器 中 的 程序 。 当 一 个 TMP 程序 运行 完成 ， 它 的 输出 一 一 从 
templates (模板 ) 实例 化 出 的 C++ 源 代 码 片 断 一 一 随后 被 正常 编译 。 


如 果 你 仅 把 它 看 作 古 怪 的 特性 而 没有 打动 你 ， 那 你 就 不 会 对 它 有 足够 的 深入 的 思 


C++ 并 不 是 为 template metaprogramming (模板 元 编程 ) 设计 的 ， 但 是 自从 TMP 在 1990 

年 代 早期 被 发 现 以 来 ， 它 已 被 证 明 非 常 有 用 ， 使 TMP 变 容 易 的 扩展 很 可 能 会 被 加 入 到 语言 和 
它 的 标准 库 之 中 。 是 的 ，TMP 是 被 发 现 ， 而 不 是 被 发 明 。TMP 所 基于 的 特性 在 

templates (模板 ) 被 加 入 C++ 的 时 候 就 已 经 被 引进 了 。 所 需要 的 全 部 就 是 有 人 注意 到 它们 能 
够 以 一 种 精巧 的 而 且 意 想不到 的 方式 被 使 用 。 


TMP 有 两 个 强大 的 力量 。 首 先 ， 它 使 得 用 其 它 方法 很 难 或 不 可 能 的 一 些 事情 变 得 容易 。 第 
二 ， 因 为 template metaprograms (模板 元 程序 ) 在 C++ 编译 期 间 执 行 ， 它 们 BENS HEM 
行 时 转移 到 编译 时 。 一 个 结果 就 是 通常 在 运行 时 才能 被 察觉 的 错误 能 够 在 编译 期 间 被 发 现 。 
另 一 个 结果 是 使 用 了 TMP 的 C++ 程序 在 以 下 几乎 每 一 个 方面 都 可 能 更 有 效率 : 更 小 的 可 执 
行 代码 ， 更 短 的 运行 时 间 ， 更 少 的 内 存 需 求 。 (然而 ， 将 工作 从 运行 时 转移 到 编译 时 的 一 个 
结果 就 是 编译 过 程 变 得 更 长 。 使 用 TMP 的 程序 可 能 比 它们 的 non-TMP 对 等 物 占用 长 得 多 的 
编译 时 间 。 ) 


考虑 228 页 引入 的 STL 的 advance 的 伪 代 码 。 (在 ltem 47。 你 现在 可 能 需要 读 那 个 Item, 
因为 在 本 Item 中 ， 我 假设 你 已 经 熟悉 了 那个 Item 的 内 容 。) 就 像 228 页 ， 我 突出 表示 代码 
中 的 伪 代 码 部 分 : 

template<typename IterT, typename DistT> 

void advance(IterT& iter, DistT d) 


if (iter is a random access iterator) { 
iter += d; // use iterator arithmetic 


} // for random access iters 
else { 
if (d >= 0) { while (d--) ++iter; } // use iterative calls to 
else { while (d++) --iter; } // ++ or -- for other 


// iterator categories 


我 们 可 以 用 typeid 把 伪 代 码 变 成 真正 的 代码 。 这 就 产生 了 一 个 解决 此 问题 的 “常规 ”的 C++ A 
法 一 一 它 的 全 部 工作 都 在 运行 时 做 : 





template<typename IterT, typename DistT> 
void advance(IterT& iter, DistT d) 


if (typeid(typename std::iterator_traits<IterT>::iterator_category) == 
typeid(std::random_access_iterator_tag)) { 


iter += d; // use iterator arithmetic 
} // for random access iters 
else { 

if (d >= 0) { while (d--) ++iter; } // use iterative calls to 

else { while (d++) --iter; } // ++ or -- for other 
} // iterator categories 


} 


Item 47 指出 这 个 typeid-based (基于 typeid) 的 方法 比 使 用 traits 的 方法 效率 低 ， 因 为 这 个 
方法 ， (1) 类 型 检测 发 生 在 运行 时 而 不 是 编译 期 (2) 用 来 做 运行 时 类 型 检测 的 代码 必须 
出 现在 可 执行 代码 中 。 实 际 上 ， 这 个 例子 展示 了 TMP 如 何 能 比 一 个 “常规 "C++ 程序 更 高 效 ， 

因为 traits 方法 是 TMP。 记 住 ，traits 人 允许 编译 时 在 类 型 上 的 if...else 计算 。 


我 先前 谈 及 一 些 事 情 在 TMP 中 比 在 “常规 "C++ 中 更 简单 ， 而 advance 提供 了 这 方面 的 一 个 例 
子 。ltem 47 提 到 advance 的 typeid-based (基于 typeid) 的 实现 可 能 会 导致 编译 问题 ， 而 这 
就 是 一 个 产生 问题 的 例子 : 


std::list<int>::iterator iter; 


advance(iter, 10); // move iter 10 elements forward; 
// won't compile with above impl. 


考虑 advance 为 上 面 这 个 调用 生成 的 版 本 。 用 iter 和 10 的 类 型 取代 template 
parameters (模板 参数 ) lterT 和 DistT 之 后 ， 我 们 得 到 这 个 : 


void advance(std::list<int>::iterator& iter, int d) 


if (typeid(std::iterator_traits<std: :list<int>::iterator>::iterator_category) == 
typeid(std::random_access_iterator_tag)) { 


iter += d; // error! 
} 
else { 
if (d >= 0) { while (d--) ++iter; } 
else { while (d++) --iter; } 
} 
} 


问题 在 突出 显示 的 行 ， 使 用 了 += 的 那 行 。 在 当前 情况 下 ， 我 们 试图 在 一 个 list<int>::iterator 
上 使 用 +=， 但 是 list<int>::iterator 是 一 个 bidirectional iterator (双向 迭代 器 ) (BR Item 
47) ， 所 以 它 不 支持 +=。 只 有 random access iterators (随机 访问 迭代 器 ) 才 支 持 +=。 此 
时 ， 我 们 知道 我 们 永远 也 不 会 试图 执行 那个 += 行 ， 因 为 那个 typeid 检测 对 于 


list<int>::iterators 永远 不 成 立 ， 但 是 编译 器 被 责成 确保 所 有 源 代 码 是 正确 的 ， 即 使 它 不 被 执 
行 ， 而 当 iter 不 是 一 个 random access iterator (随机 访问 迭代 器 ) 时 "iter += d" 是 不 正确 
的 。traits-based (基于 traits) 的 TMP 解决 方案 与 此 对 比 ， 那 里 针对 不 同类 型 的 代码 被 分 离 
到 单独 的 画 数 中 ， 其 中 每 一 个 都 只 使 用 了 可 用 于 它 所 针对 的 类 型 的 操作 。 


TMP 已 经 被 证 明 是 Turing-complete (图 灵 完 各 ) 的 ， 这 意味 着 它 强 大 得 足以 计算 任何 东西 。 
使 用 TMP， 你 可 以 声明 变量 ， 执 行 循环 ， 编 写 和 调用 画 数 ， 等 等 。 但 是 这 些 结构 看 起 来 与 其 
在 “常规 "C++ 中 的 样子 非常 不 同 。 例 如 ，ltem 47 展示 了 if...else 条 件 在 TMP 中 是 如 何 通过 
templates (模板 ) 和 ee o ase 被 表达 的 。 但 那 是 assembly- 
level (汇编 层次 ) BY TMP. 参见 Item 55) 提供 了 
一 种 更 高 层次 的 语法 ， 虽 然 还 它 误 认为 是 “常规 C++。 





为 了 一 宕 其 它 东西 在 TMP 中 如 何 工 作 ， 让 我 们 来 看 看 loops (循环 ) 。TMP 中 没有 真正 的 
looping construct (循环 结构 ) ， 因 此 loops (循环 ) 的 效果 是 通过 recursion (递归 ) 完成 
BY. (如 果 你 对 recursion ( 递 为 ) 感到 不 舒服 ， 在 你 斗 胆 进 入 TMP 之 前 一 定 要 解决 它 。 
TMP 很 大 程度 上 是 一 个 functional language (WAS) ， 而 recursion (递归 ) 之 于 
functional language (HRMHBAa) 就 像 电 视 之 于 美国 流行 文化 : 是 密 不 可 分 的 。) Am, E 
至 recursion (3% J3) 都 不 是 常规 样式 的 ， 因 为 TMP loops 不 涉及 recursive function 

calls ( 递 为 图 数 调用 ) ， 它 们 涉及 recursive template instantiations ( 递 为 模板 实例 化 ) 。 


TMP 的 "hello world" 程序 在 编译 期 间 计算 一 个 阶乘 。 它 不 是 一 个 很 伟人 兴奋 的 程序 ， 不 过 ， 
即使 不 是 "hello world"， 也 有 助 于 语言 人 门 。TMP 阶乘 计算 示范 了 通过 recursive template 
instantiation ( 递 为 模板 实例 化 ) 实现 循环 。 它 也 示范 了 在 TMP 中 创建 和 使 用 变量 的 一 种 方 
法 。 看 : 

template<unsigned n> // general case: the value of 

struct Factorial { // Factorial<n> is n times the value 


// of Factorial<n-1> 


enum { value = n * Factorial<n-1>::value }; 


}; 
template<> // special case: the value of 
struct Factorial<0> { // Factorial<0> is 1 
enum { value = 1 }; 
}; 


给 出 这 个 template metaprogram (模板 元 程序 ) (实际 上 只 是 单独 的 template 
metafunction 〈 模 板 元 函数 ) Factorial) ， 你 可 以 通过 引用 Factorial<n>::value 得 到 
factorial(n) 的 值 。 


代码 的 循环 部 分 出 现在 template instantiation (模板 实例 化 ) Factorial<n> 引用 template 
instantiation (模板 实例 化 ) Factorial<n-1> 的 地 方 。 就 像 所 有 正确 的 recursion ( 递 轨 ) 有 一 
个 导致 递 及 结束 的 特殊 情况 。 这 里 ， 它 就 是 template specialization (模板 特 化 ) 
Factorial<0>。 


Factorial template 的 每 一 个 instantiation (实例 化 ) 都 是 一 个 struct， 而 每 一 个 struct 都 使 用 
enum hack (参见 Item 2) 声明 了 一 个 名 为 value 的 TMP 变量 。value 用 于 持 有 阶乘 计算 的 
当前 值 。 如 果 TMP 有 一 个 真正 的 循环 结构 ，value 会 在 每 次 循环 时 更 新 。 因 为 TMP 在 循环 

的 位 置 使 用 recursive template instantiation ( 递 为 模板 实例 化 ) ， 每 一 个 instantiation (实例 
化 ) 得 到 它 自己 的 value 的 拷贝 ， 而 每 一 个 找 贝 拥有 适合 于 它 在 “循环 ”中 所 处 的 位 置 的 值 。 


你 可 以 和 像 这 样 使 用 Factorial : 


int main() 


std::cout << Factorial<5>::value; // prints 120 
std::cout << Factorial<i0>::value; // prints 3628800 
} 
如 果 你 觉得 这 比 吃 了 冰淇淋 还 凉快 ， 你 就 具有 了 一 个 template metaprogrammer (模板 元 程 


序 员 ) 应 有 的 素质 。 如 果 templates (模板 ) 以 及 specializations ( 特 化 ) 以 及 recursive 
instantiations (3% Ja RAHE) 以 及 enum hacks 以 及 对 类 似 Factorial<n-1>::value 这 样 的 类 型 
的 需要 使 你 毛骨悚然 ， 好 吧 ， 你 是 一 个 不 错 的 常规 C++ 程序 员 。 


当然 ，Factorial 示范 的 TMP 的 效用 大 约 就 像 "hello world" 示范 的 任何 常规 编程 语言 的 效用 一 
样 。 为 了 领会 为 什么 TMP 值得 了 解 ， 更 好 地 理解 它 能 做 什么 是 很 重要 的 。 这 里 是 三 个 示例 : 


e Ensuring dimensional unit correctness (确保 计量 单位 正确 性 ) 。 在 科学 和 工程 应 用 中 ， 
计量 单位 〈 人 例如， 质量， 距离 ， 时 间 ， 等 等 ) 被 正确 组 合 是 基础 。 例 如 ， 将 一 个 代表 质 
量 的 变量 赋值 给 一 个 代表 速度 的 变量 是 一 个 错误 ， 但 是 用 一 个 时 间 变 量 去 除 距 离 变 量 并 
将 结果 赋 给 一 个 速度 变量 就 是 正确 的 。 使 用 TMP， 不 论 计 算 多 么 复杂 ， 确 保 (在 编译 期 
间 ) 一 个 程序 中 所 有 计量 单位 组 合 都 是 正确 的 是 有 可 能 的 。 (这 是 一 个 如 何 用 TMP 进行 
早期 错误 诊断 的 例子 。) 这 个 TMP 的 使 用 的 一 个 有 趣 的 方面 是 能 够 支持 分 数 指数 。 这 需 
要 这 个 分 数 在 编译 期 间 被 简化 以 便于 编译 器 能 够 确认 ， 例 如 ， 单 位 time1/2 与 单位 
time4/8 是 相同 的 。 


Optimizing matrix operations 〈 优 化 和 矩阵 操作 ) 。ltem 21 ATEKA, Ai 
operator*， 必 须 返 回 新 的 objects, m Item 44 引入 了 SquareMatrix class， 所 以 考虑 如 
下 代码 : 


typedef SquareMatrix<double, 10000> BigMatrix; 
BigMatrix m1, m2, m3, m4, m5; // create matrices and 
// give them values 


BigMatrix result = m1 * m2 * m3 * m4 * m5; // compute their product 


用 “常规 ”方法 计算 result 需要 四 个 临时 矩阵 的 创建 ， 用 于 每 一 次 调用 operator 的 结果 。 
此 外 ， 独 立 的 乘法 产生 了 一 个 四 次 循环 通 历 矩阵 元 素 的 序列 。 使 用 一 种 与 TMP 相关 的 被 
称 为 expression templates (表达 式 模板 ) 的 高 级 模板 技术 ， 完 全 不 改变 上 面 的 客户 代码 
的 语法 ， 而 消除 临时 对 象 以 及 合并 循环 是 有 可 能 的 。 最 终 的 软件 使 用 更 少 的 内 存 而 且 运 
行 速度 戏剧 性 地 更 快 。 


e Generating custom design pattern implementations (生成 自 定义 的 设计 模式 实现 ) 。 像 
Strategy (参见 Item 35) , Observer, Visitor 等 设计 模式 能 用 很 多 方法 实现 。 使 用 一 种 
被 称 为 policy-based design (基于 policy 设计 ) 的 TMP-based (基于 TMP) 的 技术 ， 
使 得 创建 代表 独立 的 设计 选择 的 templates ("policies") 成 为 可 能 ， 这 种 templates 能 以 任 
意 的 方法 组 合 以 产生 带 有 自 定义 行为 的 模式 实现 。 例 如 ， 这 种 技术 经 常用 于 允许 几 个 实 
现 了 smart pointer behavioral (智能 指针 行为 ) 的 policies 的 templates 生成 (在 编译 期 
H) 数 百 个 不 同 的 smart pointer (智能 指针 ) 类 型 。 将 类似 设计 模式 和 智能 指针 这 样 的 
编程 器 件 的 范围 大 大 地 扩展 ， 这 项 技术 是 通常 所 说 的 generative programming (产生 式 
编程 ) 的 基础 。 


TMP 并 不 适合 于 每 一 个 人 。 它 的 语法 是 不 符合 直觉 的 ， 工 具 支 持 也 很 弱 (template 
metaprograms 的 调试 器 ? 哈 ! ) 作为 一 个 相对 晚近 才 发 现 的 “附属 "语言 ，TMP programming 
的 规则 仍然 带 有 试验 性 质 。 然 而 ， 通 过 将 工作 从 运行 时 转移 到 编译 时 所 提供 的 效率 提升 还 是 
能 给 人 留 下 深刻 的 印象 ， 而 表达 在 运行 时 很 难 或 不 可 能 实现 的 行为 的 能 力也 相当 有 吸引 力 。 


TMP 的 支持 程度 在 不 断 提升 。 很 可 能 在 C++ 的 下 一 个 版 本 中 将 对 它 提供 直接 的 支持 ， 而 且 
TR1 已 经 这 样 做 了 (参见 Item 54) 。 关 于 这 一 主题 的 书籍 也 即将 开始 出 版 (目前 ，C++ 
Template Metaprogramming: Concepts, Tools, and Techniques from Boost and Beyond 已 经 








出 版 一 一 译 者 注 ) ， 而 web 上 的 TMP 信息 也 正在 保持 增长 。TMP 也 许 永 远 不 会 成 为 主流 ， 
但 是 对 于 某 些 程序 员 特别 是 库 开 发 者 一 它 几乎 必然 会 成 为 主 料 。 


Things to Remember 


e template metaprogramming 〈 模 板 元 编程 ) 能 将 工作 从 运行 时 转移 到 编译 时 ， 这 样 就 能 
够 更 早 察觉 错误 并 提高 运行 时 性 能 。 


。 TMP 能 用 于 在 policy choices 的 组 合 的 基础 上 生成 自 定 义 代码 ， 也 能 用 于 避免 为 特殊 类 
型 生成 不 适当 的 代码 。 


Item 49: 7 #2 new-handler 的 行为 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


当 operator new 不 能 满足 一 个 内 存 分 配 请 求 时 ， 它 抛 出 一 个 exception (F) 。 很 久 以 
前 ， 他 返回 一 个 null pointer (〈 空 指针 ) ， 而 一 些 比 较 老 的 编译 器 还 在 这 样 做 。 你 依然 能 得 到 
以 前 的 行为 〈 在 一 定 程 度 上 ) ， 但 是 我 要 到 这 个 Item 的 最 后 再 讨论 它 。 

在 operator new 因 回 应 一 个 无 法 满足 的 内 存 请 求 而 抛 出 一 个 exception 之 前 ， 它 先 调 用 一 
可 以 由 客户 指定 的 被 称 为 new-handler 的 ED function 〈 错 误 处 理 函 数 ) 。 (这 并 
不 完全 确切 ，operator new 真正 做 的 事情 比 这 个 稍微 复 末 一 些 ， 详 细 细 节 在 ltem 51 fe 


供 。) 为 了 指定 out-of-memory-handling function， 客 户 调用 set_new_handler 一 一 一 个 在 
<new> 中 声明 的 标准 库 图 数 : 


namespace std { 


typedef void (*new_handler)(); new_handler set_new_handler(new_handler p) throw(); } 


就 像 你 能 够 看 到 的 ，new_handler 是 一 个 指针 的 typedef, XMEHHAAREARE Ese, TM set_ne 
set_new_handler 的 形 参 是 一 个 指向 函数 的 指针 ， 这 个 画 数 是 operator new 无 法 分 配 被 请 求 的 内 存 时 应 该 调用 的 。 


你 可 以 像 这 样 使 用 set_new_handler : 


E __&§ 





// function to call if operator new can't allocate enough memory void outOfMem() { std::cerr 
<< "Unable to satisfy request for memory/n"; std::abort(); } int main() { 
std::set_new_handler(outOfMem); int *pBigDataArray = new int[100000000L); ... } 


如 果 operator new 不 能 为 100,000,000 个 整数 分 配 空间 ，out0fMem 将 被 调用 ， 而 程序 将 在 发 出 一 个 错误 信息 后 
当 operator new 不 能 满足 一 个 内 存 请 求 时 ， 它 反复 调用 new-handler function 直到 它 能 找到 足够 的 内 存 。 引 走 
* Make more memory available (使 得 更 多 的 内 存 可 用 ) 。 这 可 能 使 得 operator new 中 下 一 次 内 存 分 配 的 尝试 . 
* Install a different new-handler (安装 一 个 不 同 的 new-handler) 。 如 果 当 前 的 new-handler 不 能 做 至 
* Deinstall the new-handler (#2 new-handler) ， 也 就 是 ， 将 空 指针 传 给 set_new_handler。 没 有 new 
* Throw an exception (〈 抛 出 一 个 异常 ) ， 类 型 为 bad_alloc 或 继承 自 bad_alloc 的 其 它 类 型 。 这 样 的 异常 不 
* Not return (不 再 返回 ) ， 典 型 情况 下 ， 调 用 abort 或 exit. 

这 些 选择 使 你 在 实现 new-handler functions 时 拥有 极 大 的 弹性 。 


有 时 你 可 能 希望 根据 被 分 配 object 的 不 同 ， 用 不 同 的 方法 处 理 内 存 分 配 的 失败 : 


Ej _ 





class X { public: static void outOfMemory(); ... }; class Y { public: static void outOfMemory(); 
... }; X* p1 = new X; // if allocation is unsuccessful, // call X::outOfMemory 


Y* p2 = new Y; // if allocation is unsuccessful, // call Y::outOfMemory 


C++ 没有 对 class-specific new-handlers 的 支持 ， 但 是 它 也 不 需要 。 你 可 以 自己 实现 这 一 行为 。 你 只 要 让 每 一 1 


假设 你 要 为 Widget class 义理 内 存 分 配 失败 。 你 就 必须 清楚 当 operator new 不 能 为 一 个 Widget object 分 本 
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class Widget { public: static std::new_handler set_new_handler(std::new_handler p) throw(); 
static void * operator new(std::size_t size) throw(std::bad_alloc); private: static 
std::new_handler currentHandler; }; 


static class members (静态 类 成 员 ) 必须 在 class 定义 外 被 定义 (除非 它们 是 const MHZ integral —Z 





std::new_handler Widget::currentHandler = 0; // init to null in the class // impl. file 


Widget 中 的 set_new_handler 画 数 会 保存 传递 给 它 的 任何 指针 ， 而 且 会 返回 前 次 调用 时 被 保存 的 任何 指针 ， 这 也 正 


LE 





std::new_handler Widget::set_new_handler(std::new_handler p) throw() { std::new_handler 
oldHandler = currentHandler; currentHandler = p; return oldHandler; } 


BA, Widget 的 operator new 将 做 下 面 这 些 事情 : 

1\. 以 Widget 的 error-handling function 为 参数 调用 standard set_new_handler. #4} Widget 上 
2\， 调用 global operator new 进行 真正 的 内 存 分 配 。 如 果 分 配 失败 ，global operator new 调用 Widget É 
3\. 如 果 global operator new 能 够 为 一 个 Widget object 分 配 足 够 的 内 存 ，Widget 的 operator new 3% 


以 下 就 是 你 如 何在 C++ 中 表达 这 所 有 的 事情 。 我 们 以 resource-handling class 开始 ， 组 成 部 分 中 除了 基本 的 R 
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class NewHandlerHolder { public: explicit NewHandlerHolder(std::new_handler nh) // acquire 
current :handler(nh) {} // new-handler 


~NewHandlerHolder() // release it { std::set_new_handler(handler); } private: 
std::new_handler handler; // remember it 


NewHandlerHolder(const NewHandlerHolder&); // prevent copying NewHandlerHolder& // 
(see Item 14) operator=(const NewHandlerHolder&); }; 


这 使 得 Widget 的 operator new 的 实现 非常 简单 : 
void * Widget::operator new(std::size_t size) throw(std::bad_alloc) { NewHandlerHolder // 
install Widget's h(std::set_new_handler(currentHandler)); // new-handler 


return ::operator new(size); // allocate memory // or throw 


} // restore global // new-handler 


Widget 的 客户 像 这 样 使 用 它 的 new-handling capabilities (处 理 new 的 能 力 ) : 


void outOfMem(); // decl. of func. to call if mem. alloc. // for Widget objects fails 
Widget::set_new_handler(outOfMem); // set outOfMem as Widget's // new-handling function 
Widget *pw1 = new Widget; // if memory allocation // fails, call outOfMem 


std::string *ps = new std::string; // if memory allocation fails, // call the global new-handling // 
function (if there is one) 


Widget::set_new_handler(0); // set the Widget-specific // new-handling function to // nothing 
(i.e., null) 


Widget *pw2 = new Widget; // if mem. alloc. fails, throw an // exception immediately. (There 
is // no new- handling function for // class Widget.) 


无 论 class 是 什么 ， 实 现 这 个 方案 的 代码 都 是 一 样 的 ， 所 以 在 其 它 地 方 重 用 它 就 是 一 个 合理 的 目标 。 使 它 成 为 可 能 的 一 


这 个 设计 的 base class ( 基 类 ) 部 分 让 derived classes (派生 类 ) 继承 它们 全 都 需要 的 set_new_handler 和 








template // "mixin-style" base class for class NewHandlerSupport{ // class-specific 
set_new_handler public: // support 


static std::new_handler set_new_handler(std::new_handler p) throw(); static void * operator 
new(std::size_t size) throw(std::bad_alloc); 


... // other versions of op. new — // see Item 52 private: static std::new_handler 
currentHandler; }; 


template std::new_handler NewHandlerSupport::set_new_handler(std::new_handler p) 
throw() { std::new_handler oldHandler = currentHandler; currentHandler = p; return 
oldHandler; } 


template void* NewHandlerSupport::operator new(std::size_t size) throw(std::bad_alloc) { 
NewHandlerHolder h(std::set_new_handler(currentHandler)); return ::operator new(size); } // 
this initializes each currentHandler to null template std::new_handler 
NewHandlerSupport::currentHandler = 0; 


有 了 这 个 class template (类 模板 ) ， 为 Widget 增加 set_new_handler 支持 就 很 容易 了 : Widget 只 需要 从 
EE SS. 


NewHandlerSupport 继承 即 可 。 (可 能 看 起 来 很 奇特 ， 但 是 下 面 我 将 解释 更 多 的 细节 。 ) 





class Widget: public NewHandlerSupport { … // as before, but without declarations for }; // 
set_new_handler or operator new 


这 些 就 是 Widget 为 了 提供 一 个 class-specific set_new_handler 所 需要 做 的 全 部 。 

但 是 也 许 你 依然 在 为 Widget 从 NewHandlerSupport&lt;Widget&agt; 继承 而 烦恼 。 如 果 是 这 样 ， 当 你 注意 到 Ne 
对 于 Widget 从 一 个 把 widget 当 作 一 个 type parameter (类 型 参数 ) 的 templatized base class (模板 化 
在 这 一 点 上 ， 我 发 表 了 一 篇 文章 建议 一 个 更 好 的 名 字 叫 做 "Do It For Me"， 因 为 当 Widget 从 NewHandlerSuppo 
像 NewHandlerSupport 这 样 的 templates 使 得 为 任何 有 需要 的 class 添加 一 个 class-specific new-hanc 


直到 1993 年 ，C++ 还 要 求 operator new 不 能 分 配 被 请 求 的 内 存 时 要 返回 null。operator new 现在 则 被 指定 : 
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class Widget { ... }; Widget *pw1 = new Widget; // throws bad_alloc if // allocation fails 


if (pw1 == 0) ... // this test must fail 


Widget *pw2 =new (std::nothrow) Widget; // returns 0 if allocation for // the Widget fails 
if (pw2 == 0) ... // this test may succeed `` 


对 于 异常 ，nothrow new 提供 了 比 最 初 看 上 去 更 少 的 强制 保证 。 在 表达 式 "new (std::nothrow) 
Widget" 中 ， 发 生 了 两 件 事 。 首 先 ，operator new 的 nothrow 版 本 被 调用 来 为 一 个 Widget 
object 分 配 足 够 的 内 存 。 如 果 这 个 分 配 失 败 ， 众 所 周知 ，operator new 返回 null pointers Z 
而 ， 如 果 它 成 功 了 ，Widget constructor 被 调用 ， 而 在 此 刻 ， 所 有 打 的 赌 都 失效 了 。Widget 
constructor 能 做 任何 它 想 做 的 事 。 它 可 能 自己 new 出 来 一 些 内 存 ， 而 如 果 它 这 样 做 了 ， 它 并 
没有 被 强迫 使 用 nothrow new。 那 么 ， 虽 然 在 "new (std::nothrow) Widget" 中 调用 的 operator 
new 不 会 抛 出 ，Widget constructor 却 可 以 。 如 果 它 这 样 做 了 ，exception 像 往常 一 样 被 传 
播 。 结 论 ?使 用 nothrow new 只 能 保证 Operator new 不 会 抛 出 ， 不 能 保证 一 个 像 "new 
(std::nothrow) Widget" 这 样 的 表达 式 绝 不 会 导致 一 个 exception。 在 所 有 的 可 能 性 中 ， 你 最 好 
绝 不 需要 nothrow new。 


无 论 你 是 使 用 "normal" (也 就 是 说 ，exception-throwing) new， 还 是 它 的 稍微 有 些 矮小 的 堂 
兄弟 ， 理 解 new-handler 的 行为 是 很 重要 的 ， 因 为 它 可 以 用 于 两 种 形式 。 


Things to Remember 
e set_new_handler 人 允许 你 指定 一 个 当 内 存 分 配 请 求 不 能 被 满足 时 可 以 被 调用 的 范 数 。 


e nothrow new 作用 有 限 ， 因 为 它 仅 适用 于 内 存 分 配 ， 随 后 的 constructor 调用 可 能 依然 会 
HiH exceptions. 


Item 50: 领会 何 时 替换 new 和 delete 才 有 意义 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


让 我 们 先 回顾 一 下 基础 。 为 什么 有 些 人 想 要 车 换 编 译 器 提供 的 operator new 或 operator 
delete 版 本 呢 ? 有 三 个 最 主要 的 原因 : 


。 为 了 监测 使 用 错误 。 对 由 new 产生 的 内 存 没有 实行 delete 会 导致 内 存 泄漏 。 在 new 出 
的 内 存 上 实行 多 于 一 次 的 delete 会 引发 未 定义 行为 。 如 果 operator new 保存 一 个 已 分 配 
地 址 的 列表 ， 而 operator delete 从 这 个 列表 中 移 除 地 址 ， 这 样 就 很 容易 监测 到 上 述 使 用 
i, 同样 ， 某 种 编程 错误 会 导致 data overruns (数据 上 浴 ) (在 一 个 已 分 配 块 的 末端 
ZESA) 和 underruns (FA) (在 一 个 已 分 配 块 的 始 端 之 前 写 入 ) 。 在 对 于 客户 可 用 
的 内 存 的 之 前 和 之 后 ， 自 定义 operator news 可 以 跨越 分 配 块 ， 在 这 些 空间 放置 已 知 的 字 
节 模 式 ("signatures")。operator deletes 会 去 检查 这 些 signatures 是 否 依 旧 保 持原 样 。 如 
果 不 是 ， 在 这 个 分 配 块 的 生存 期 间 的 某 个 时 刻 发 生 了 一 个 上 浴 或 者 下 浴 ， 而 且 operator 
deletes 可 以 记录 这 件 事 以 及 那个 讨厌 的 指针 的 值 。 


。 为 了 提升 性 能 。 由 编译 器 加 载 的 operator new 和 operator delete 版 本 是 为 了 多 种 用 途 而 
设计 的 。 它 们 必须 被 长 时 间 运 行 的 程序 (例如 ，web servers) ， 接 受 ， 但 是 ， 它 们 也 必 
须 被 运行 时 间 少 于 一 秒 的 程序 接受 。 它 们 必须 处 理 大 内 存 块 ， 小 内 存 块 ， 以 及 两 者 混合 
的 请 求 序列 。 它 们 必须 适应 广泛 的 分 配 模式 ， 从 存在 于 整个 程序 的 持续 期 间 的 少数 几 个 
区 块 的 动态 分 配 到 大 量 短 寿命 objects 的 持续 不 断 的 分 配 和 释放 。 它 们 必须 为 堆 碎 片 化 负 
责 ， 对 这 个 过 程 ， 如 果 不 进行 控制 ， 最 终 会 导致 不 能 满足 对 大 内 存 块 的 请 求 ， 即 使 有 足 
够 的 自由 内 存 分 布 在 大 量 小 块 中 。 


由 于 内 存 管理 器 的 特定 需求 ， 由 编译 器 加 载 的 operator news 和 operator deletes 采取 了 
middle-of-the-road strategy (中 间 路 线 策略 ) 不 值得 大 惊 小 怪 。 它 们 的 工作 对 每 一 个 人 
来 说 都 说 得 过 去 ， 但 是 对 谁 都 不 是 最 合适 的 。 如 果 你 对 你 的 程序 的 动态 内 存 的 应 用 模式 
有 充分 的 理解 ， 你 可 能 经 常 发 现 operator new 和 operator delete AUB LARA HEF RG 
版 本 。 对 于 “ 胜 于 "”， 我 的 意思 是 它们 运行 更 快 一 二 有 时 会 有 数量 级 的 提升 一 一 而 且 它 们 需 
要 更 少 的 内 存 一 一 最 高 会 少 于 50%。 对 于 某 些 (尽管 不 意味 着 全 部 ) 应 用 程序 ， 用 自 定 
义 版 本 取代 普通 的 new 和 delete 是 获得 重大 性 能 提升 的 一 个 简单 方法 。 














© 为 了 收集 使 用 方法 的 统计 数据 。 在 一 头 扎 和 人 编写 自 定义 news 和 deletes 的 道路 之 前 ， 收 
集 一 下 你 的 软件 如 何 使 用 动态 内 存 的 信息 还 是 比较 明智 的 。 被 分 配 区 块 大 小 的 分 布 如 
何 ? 生存 期 的 分 布 如 何 ? 它们 的 分 配 和 释放 的 顺序 是 趋向 于 FIFO ("first in, first out") 

(“先进 先 出 ”) ， 或 者 LIFO ("last in, first out") (“后 进 先 出 ”) 的 顺序 ， 还 是 某 种 接近 于 随 
机 的 顺序 ? 使 用 模式 会 随 着 时 间 而 变化 吗 ? 例 如， 你 的 软件 是 不 是 在 不 同 的 运行 阶段 有 


不 同 的 分 配 /释放 模式 ?在 任 一 时 间 内 使 用 中 的 动态 分 配 内 存 的 最 大 值 (也 就 是 说 ， 它 


的 “最 高 水 位 ”) 是 多 少 ? operator new 和 operator delete 的 自 定义 版 本 使 得 收集 这 类 信 
息 变 得 容易 。 


在 概念 上 ， 编 写 一 个 自 定义 operator new 相当 简单 。 例 如 ， 这 是 一 个 便于 under- 和 
overruns 的 检测 的 global operator new 的 主要 部 分 。 这 里 有 很 多 小 麻烦 ， 但 是 我 们 马上 就 来 
关注 一 下 它们 。 


static const int signature = OxDEADBEEF; 
typedef unsigned char Byte; 


// this code has several flaws—see below 
void* operator new(std::size_t size) throw(std::bad_alloc) 


using namespace std; 


size_t realSize = size + 2 * sizeof(int); // increase size of request so2 
// signatures will also fit inside 


void *pMem = malloc(realSize); // call malloc to get theactual 
if (!pMem) throw bad_alloc(); // memory 


// write signature into first and last parts of the memory 
*(static_cast&lt;int*&gt;(pMem)) = signature; 

*(reinterpret_cast&lt;int*&gt; (static_cast&lt;Byte*&gt; (pMem)+realSize-sizeof(int))) = 
signature; 


// return a pointer to the memory just past the first signature 
return static_cast&lt;Byte*&gt;(pMem) + sizeof(int); 


4 — Ti 


这 个 operator new 的 大 多 数 缺 陷 都 与 它 没有 遵循 叫 这 个 名 字 的 函数 的 C++ 惯例 有 关 。 例 

如 ，ltem 51 阐明 : 所 有 的 operator new 都 应 该 包含 一 个 调用 new-handling function 的 循 
环 ， 但 是 这 里 没有 。 但 是 ，ltem 51 正 是 专用 于 这 样 的 惯例 ， 所 以 我 在 这 里 忽略 它们 。 我 现在 
要 关注 一 个 更 微妙 的 问题 : alignment (排列 对 齐 ) 。 


很 多 计算 机 架构 要 求 特 定 类 型 的 数据 要 放置 在 内 存 中 具有 特定 性 质 的 地 址 中 。 例 如 ， 一 种 架 

构 可 能 要 求 pointers (指针 ) 要 出 现在 四 的 倍数 的 地 址 上 (也 就 是 说 ， 按 照 四 字 节 对 齐 ) 或 者 
doubles 〈 双 精度 浮 点 型 ) 必须 出 现在 八 的 倍数 的 地 址 上 (也 就 是 说 ， 按 照 八字 节 对 齐 ) 。 不 
遵守 这 样 的 约束 会 导致 hardware exceptions at runtime (运行 时 硬件 异常 ) 。 其 它 的 架构 可 

能 会 宽容 一 些 ， 但 是 如 果 满 足 了 排列 对 齐 的 次 序 会 得 到 更 好 的 性 能 。 例 如 ， 在 Intel x86 架构 
上 doubles 〈 双 精度 浮 点 型 ) 可 以 按照 任意 字 节 分 界 排列 ， 但 是 如 果 他 们 按照 八字 节 对 齐 ， 访 
问 速 度 会 快 得 多 。 


alignment (排列 对 齐 ) 在 这 里 有 重大 意义 ， 因 为 C++ 要 求 所 有 的 operator news 返回 适合 任 
何 数据 类 型 的 排列 的 指针 。malloc 也 工作 于 同样 的 要 求 下 ， 所 以 ， 让 operator new 返回 它 从 
malloc 得 到 的 指针 是 安全 的 。 然 而 ， 在 上 面 的 operator news 中 ， 我 们 没有 返回 我 们 从 
malloc 得 到 的 指针 ， 我 们 返回 的 指针 比 我 们 从 malloc 得 到 的 指针 偏 移 了 一 个 int 大 小 。 无 法 
保证 这 是 安全 的 | 如 果 客 户 调用 operator new 为 一 个 double (或 者 ， 如 果 我 们 正在 编写 


operator new[]， 一 个 doubles 的 数组 ) 申请 足够 的 内 存 ， 而 且 我 们 正在 运行 一 台 ints 是 四 个 
字 节 大 小 而 doubles 需要 八字 节 对 齐 的 机 器 ， 我 们 就 可 能 返回 对 齐 不 恰当 的 指针 。 这 可 以 导 
致 程序 崩溃 。 或 者 ， 它 只 是 导致 运行 速度 变 慢 。 无 论 哪 种 情况 ， 这 或 许 都 不 是 我 们 想 要 的 。 


像 alignment (排列 对 齐 ) 这 样 的 细节 可 以 用 于 区 分 专业 品质 的 内 存 管 理 器 和 那些 由 需要 解决 
其 它 任务 而 心烦 意 乱 的 程序 员 匆匆 拼凑 出 来 的 东西 。 编 写 一 个 几乎 能 工作 的 自 定义 内 存 管 理 
器 相当 容易 。 编 写 一 个 工作 得 很 好 的 要 困难 得 多 。 作 为 一 个 一 般 规 则 ， 我 建议 你 不 要 致力 于 
此 ， 除 非 你 不 得 不 做 。 


很 多 情况 下 ， 你 并 非 不 得 不 做 。 有 些 编 译 器 提供 选项 开关 用 为 它们 的 memory management 
functions (内存 管 理 函 数 ) 打开 调试 和 记录 的 功能 。 快 速 浏览 一 下 你 的 编译 器 的 文档 也 许可 
以 打消 你 编写 new 和 delete 的 念头 。 在 很 多 平台 上 ， 商 用 产品 可 以 蔡 代 随 编译 器 提供 的 
memory management functions 〈 内 存 管理 函数 ) 。 为 了 利用 它们 的 增强 的 功能 以 及 (或许 会 
有 的 ) 更 好 的 性 能 ， 你 需要 做 的 全 部 就 是 重新 链接 。 (当然 ， 你 还 必须 把 它们 买 回来 。) 


另 一 个 选择 是 开源 的 内 存 管 理 器 。 它 们 可 用 于 多 种 平台 ， 所 以 你 可 以 下 载 并 试用 。 出 自 于 
Boost (参见 ltem 55) 的 Pool library 就 是 一 个 这 样 的 开源 分 配器 。Pool library 提供 了 针对 
自 定 义 内 存 管理 能 提供 帮助 的 最 通常 的 情况 之 一 〈 大 数量 small objects (小 对 象 ) 的 分 配 ) 
进行 了 调谐 的 分 配器 。 很 多 C++ 书籍 ， 包 括 本 书 的 早期 版 本 ， 展 示 了 一 个 high-performance 
small-object allocator (高 性 能 小 对 象 分 配器 ) 的 代码 ， 但 是 它们 通常 忽略 了 可 移植 性 和 排列 
对 齐 的 考虑 以 及 线程 安全 等 等 诸如 此 类 的 麻烦 的 细节 。 真 正 的 库 会 注意 用 健壮 得 多 的 代码 。 
即使 你 决定 编写 你 自己 的 news 和 deletes， 看 一 下 开源 版 本 很 可 能 会 为 你 提供 对 “区 分 几乎 起 
作用 和 真正 起 作用 "的 容易 忽略 的 细节 的 洞察 力 。 (已 知 alignment (排列 对 齐 ) 就 是 一 个 这 
样 的 细节 ， 值 得 一 提 的 是 ，TR1 (参见 ltem 54) 包含 了 对 已 发 现 的 类 型 特定 的 排列 对 齐 要 求 
的 支持 。) 


这 个 Item 的 主题 是 了 解 何 时 替换 new 和 delete 的 缺 省 版 本 (无 论 是 基于 全 局 的 还 是 per- 
class 的 ) 才 有 意义 。 我 们 现在 应 该 比 前 面 更 详细 地 总 结 一 下 时 机 问题 。 


。 为 了 监测 使 用 错误 〈 如 前 ) 。 
。 为 了 收集 有 关 动 态 分 配 内 存 的 使 用 的 统计 数据 (MOAT) 。 


。 为 了 提升 分 配 和 回收 的 速度 。general-purpose allocators (通用 目的 的 分 配器 ) 通常 (a 
然 不 总 是 ) 比 自 定 义 版 本 慢 很 多 ， 特 别 是 如 果 自 定义 版 本 是 为 某 种 特定 类 型 的 objects 专 
门 设 计 的 。class-specific allocators (类 专用 分 配器 ) 是 fixed-size allocators (固定 大 小 
分 配器 ) (就 像 Boost BY Pool library 所 提供 的 那些 ) 的 一 种 典范 上 应用。 如 果 你 的 程序 是 
single-threaded (单线 程 )》 的， 而 你 的 编译 器 缺 省 的 内 存 管 理 例 程 是 thread-safe (线程 
安全 ) 的 ， 通 过 编写 thread-unsafe allocators ( 非 线程 安全 分 配器 ) 你 可 以 获得 相当 的 
速度 提升 。 当 然 ， 在 得 出 operator new 和 operator delete 对 速度 提升 有 价值 的 结论 之 
前 ， 确 实测 定 你 的 程序 以 保证 这 些 函 数 是 真正 的 瓶颈 。 


。 为 了 减少 缺 省 内 存 管理 的 空间 成 本 。general-purpose memory managers (通用 目的 的 内 
存 管理 器 ) 通常 (虽然 不 总 是 ) 不 仅 比 自 定义 版 本 慢 ， 而 且 还 经 常 使 用 更 多 的 内 存 。 这 
是 因为 它们 经 常 为 每 个 已 分 配 区 块 招致 某 些 成 本 。 针 对 small objects (小 对 象 ) 调谐 的 
分 配器 (诸如 Boost 的 Pool library 中 的 那些 ) 从 根本 上 消除 了 这 样 的 成 本 。 


为 了 调整 缺 省 分 配器 不 适当 的 排列 对 齐 。 就 像 我 前 面 提 到 的 ， 在 x86 架构 上 ， 当 
doubles 按照 八字 节 对 齐 时 访问 速度 是 最 快 的 。 哎 呀 ， 有 些 随 编 译 器 提供 的 operator 
news 不 能 保证 doubles 的 动态 分 配 按照 八字 节 对 齐 。 在 这 种 情况 下 ， 用 保证 按照 八字 节 
对 齐 的 operator new 替换 掉 缺 省 版 本 ， 可 以 使 程序 性 能 得 到 较 大 提升 。 


。 为 了 聚集 相关 的 objects， 使 它们 彼此 靠近 。 如 果 你 知道 特定 的 data structures (数据 结 
构 ) 通常 会 在 一 起 使 用 ， 而 且 你 想 将 在 这 些 数 据 上 工作 时 的 页 错误 频率 降 到 最 低 ， 那 么 
为 这 些 data structures (数据 结构 ) 创建 一 个 独立 的 heap (HE) 以 便 让 它们 尽 可 能 地 聚 
集 在 不 多 的 几 个 页 上 就 是 有 意义 的 。new 和 delete 的 placement versions (参见 Item 
52) 使 得 完成 这 样 的 聚集 成 为 可 能 。 


。 为 了 获得 不 同 寻常 的 行为 。 有 时 你 想 让 operators new 和 delete 做 一 些 编译 器 装备 版 本 
没有 提供 的 事情 。 例 如 ， 你 可 能 想 在 共享 内 存 中 分 配 和 回收 区 块 ， 但 是 只 能 通过 一 个 C 
API 来 管理 那 片 内 存 。 编 写 new 的 delete 的 自 定义 版 本 (或 许 是 placement versions 
一 一 再 次 参见 Item 52) 人 允许 你 用 C++ 衣服 来 遮 住 那个 C API。 作 为 另 一 个 例子 ， 你 可 
以 编写 一 个 自 定 义 的 operator delete 用 zeros 复写 被 回收 的 内 存 以 提高 应 用 程序 数据 的 
安全 性 。 


Things to Remember 


。 有 很 多 正当 的 编写 new 和 delete 的 自 定义 版 本 的 理由 ， 包 括 改进 性 能 ， 调 试 
heap (HE) 用 法 错误 ， 以 及 收集 heap (HE) 用 法 信息 。 


Item 51: 445 new 和 delete 时 要 遵守 惯例 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


Item 50 讲解 了 什么 时 候 你 可 能 需要 编 守 operator new 和 operator delete 的 你 自己 的 版 本 ， 
但 是 没有 讲解 当 你 这 样 做 时 必须 遵循 的 惯例 。 这 些 规则 并 不 难以 遵循 ， 但 有 一 些 不 那么 直 
观 ， 所 以 了 解 它们 是 什么 非常 重要 。 


我 们 从 operator new 开始 。 实 现 一 个 符合 惯例 的 operator new 需要 有 正确 的 返回 值 ， 在 没有 
足够 的 内 存 可 用 时 调用 new-handling function (参见 Item 49) ， 并 做 好 应 付 无 内 存 请 求 的 准 
备 。 你 还 要 避免 无 意 中 对 new 的 “常规 ”形式 的 覆盖 ， 哩 然 这 更 多 的 是 一 个 class interface (类 
接口 ) 的 问题 ， 而 并 非 是 一 个 实现 的 需求 ， 它 将 在 ltem 52 讨论 。 


operator new 的 返回 值 部 分 很 容易 。 如 果 你 能 提供 所 请 求 的 内 存 ， 你 就 返回 一 个 指向 它 的 指 
针 。 如 果 你 不 能 ， 你 应 该 遵循 ltem 49 描述 的 规则 并 抛 出 一 个 bad_alloc 类 型 的 
exception (异常 ) 。 


然而 ， 它 也 不 完全 那么 简单 ， 因 为 operator new 实际 上 不 止 一 次 设法 分 配 内 存 ， 每 次 失败 后 
调用 new-handling function。 在 此 假设 new-handling function 能 做 些 事情 释放 一 些 内 存 。 只 
有 当 指 向 new-handling function 的 指针 为 空 时 ，operator new 才 抛 出 一 个 exception (= 
常 ) 。 


奇怪 的 是 ，C++ 要 求 即使 请 求 需 字 节 ，operator new 也 要 返回 一 个 合理 的 指针 。 (需要 这 种 
怪异 的 行为 来 简 化 语言 的 其 它 部 分 。) 在 这 种 情况 下 ， 一 个 non-member ( 非 成 员 ) 的 
operator new 的 伪 代 码 如 下 : 


void * operator new(std::size_t size) throw(std::bad_alloc) 


{ // your operator new might 
using namespace std; // take additional params 
if (size == 0) { // handle 0-byte requests 

size = 1; // by treating them as 
} // 1-byte requests 


while (true) { 
_attempt to allocate size bytes;_ 
if (_the allocation was successful_) 
return (_a pointer to the memory_); 


// allocation was unsuccessful; find out what the 
// current new-handling function is (see below) 
new_handler globalHandler = set_new_handler(0); 
set_new_handler(globalHandler ); 


if (globalHandler) (*globalHandler)(); 
else throw std::bad_alloc(); 
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法 ， 有 效 ， 无 论 如 何 ， 你 估 摸 着 的 请 求 雳 字 节 这 种 事情 发 生 的 频率 有 多 大 呢 ? 


你 可 能 在 不 经 意 中 还 看 到 伪 代 码 中 将 new-handling function pointer 设置 为 空 ， 然 后 又 马上 重 
置 为 它 原 来 的 值 。 遗 憾 的 是 ， 没 有 办 法 直接 得 到 new-handling function pointer， 所 以 你 必须 
调用 set_new_handler 以 得 知 它 是 什么 。 拙 劣 ， 的 确 ， 但 是 也 有 效 ， 至 少 对 single- 

threaded (单线 程 ) 代码 没 问题 。 在 multithreaded (多 线程 ) 环境 中 ， 你 可 能 需要 某 种 锁 以 
便 安 全 地 摆布 隐藏 在 new-handling function 后 面 的 (全 局 的 ) data structures (数据 结构 ) 。 


ltem 49 谈 及 operator new 包含 一 个 无 限 循环 ， 而 上 面 的 代码 明确 地 展示 了 这 个 循环 ，"while 
(true)" 差不多 会 尽 其 所 能 地 无 限 做 下 去 。 跳 出 循环 的 唯一 出 路 是 内 存 被 成 功 分 配 或 new- 
handling function 做 了 Item 49 中 描述 的 事情 之 一 : 使 得 更 多 的 内 存 可 用 ， 安 装 一 个 不 同 的 
new-handler, #3 new-handler， 抛 出 一 个 bad_alloc 或 从 bad_alloc 派生 的 exception (= 
常 ) ， 或 不 再 返回 。 现 在 ，new-handler 为 什么 要 做 这 些 事情 之 一 已 经 很 清楚 了 。 如 果 它 不 这 
样 做 ，operator new 内 的 循环 永远 不 会 停止 。 


很 多 人 没有 意识 到 operator new member functions (AK ANAL) 会 被 derived classes (派生 
类 ) 继承 。 这 会 引起 一 些 有 趣 的 复 灯 性 。 在 前 面 的 operator new 伪 代 码 中 ， 注 意 那个 画 数 设 
法 分 配 size 个 字 节 (除非 size 是 需 ) 。 因 为 它 是 传递 给 这 个 图 数 的 argument (LB) ， 所 
以 它 有 着 明确 的 意义 。 然 而 ， 就 像 ltem 50 所 讲 的 ， 编 写 一 个 自 定义 的 内 存 管理 器 的 最 常见 的 
原因 之 一 是 为 了 优化 某 个 特定 class 的 objects 的 分 配 ， 而 不 是 某 个 class 或 它 的 任何 
derived classes (派生 类 ) 的 。 也 就 是 说 ， 给 定 一 个 class X 的 operator new， 这 个 加 数 的 行 
为 通常 是 为 大 小 为 sizeof(X) 的 objects 调谐 的 绝 不 会 更 大 或 者 更 小 。 然 而 ， 由 于 
inheritance (继承 ) ， 就 有 可 能 一 个 base class ( 基 类 ) 中 的 operator new 被 调用 来 为 一 个 
derived class (派生 类 ) 的 object 分 配 内 存 : 





class Base { 
public: 
**static void * operator new(std::size_t size) throw(std::bad_alloc)**; 


T 


class Derived: public Base // Derived doesn't declare 
a i // operator new 
Derived *p = **new Derived**; // calls Base::operator new! 


如 果 Base 的 class-specific (类 专用 ) 的 operator new 不 是 被 设计 成 应 付 这 种 情况 的 它 
很 可 能 不 是 一 一 它 处 理 这 种 局 面 的 最 佳 办 法 就 是 把 这 个 请 求 “ 错 误 ” 内 存量 的 调用 甩 给 standard 
Operator new， 就 像 这 样 : 





void * Base::operator new(std::size_t size) throw(std::bad_alloc) 
**if (size != sizeof(Base) )** // if size is "wrong," 
**return ::operator new(size)**; // have standard operator 
// new handle the request 


// otherwise handle 
// the request here 


“Rye ah | "我 听 到 你 喊 , “你 忘 了 检查 size Bix FF pathological-but-nevertheless- 

possible (病态 然而 可 能 ) 的 情况 ! "实际 上 ， 我 没有 ， 还 有 ， 当 你 大 声 抱怨 的 时 候 拜 托 不 要 
使 用 连 字 符 。 测 试 依然 在 那 ， 它 只 是 与 size 和 sizeof(Base) 的 比较 合 在 了 一 起 。C++ 工作 在 
一 些 神秘 的 方式 中 ， 这 些 方式 之 一 就 是 强制 规定 所 有 的 独立 objects 都 具有 非 需 的 大 小 〈 参 见 
ltem 39) 。 根 据 定义 ，sizeof(Base) 绝 不 会 是 需 ， 所 以 如 果 size 是 需 ， 请 求 料 转发 给 
operator new， 而 以 一 种 合理 的 方式 处 置 这 个 请 求 就 成 为 那个 琅 数 的 职责 。 


如 果 你 想 要 在 每 一 个 class 的 基础 上 控制 数组 的 内 存 分配 ， 你 需要 实现 operator new 的 专用 
于 数组 的 兄弟 ，operator new[]。 (这 个 function 通常 被 叫做 "array new"， 因 为 要 确定 
"operator new[]" 如 何 发 音 实在 是 太 难 了 。) 如 果 你 决定 要 编写 operator new[]， 记 住 你 所 做 
的 全 部 是 分 配 一 大 块 raw memory (AN) 你 不 能 针对 还 不 存在 的 数组 中 的 objects 做 
任何 事情 。 实 际 上 ， 你 其 至 不 能 确定 数组 中 会 有 多 少 个 objects。 首 先 ， 你 不 知道 每 个 object 
AZA. #5, —^® base class ( 基 类 ) 的 operator new[] 通过 继承 可 以 被 调用 来 为 一 个 
derived class objects (派生 类 对 象 ) 的 数组 分 配 内 存 ， 而 derived class objects (派生 类 对 
象 ) 通常 都 比 base class objects ( 基 类 对 象 ) 更 大 。 





因此 ， 在 Base::operator newl] 中 ， 你 不 能 断定 每 一 个 加 到 数组 中 的 object 的 大 小 一 定 是 
sizeof(Base)， 而 这 就 意味 着 ， 你 不 能 断定 数组 中 的 objects 的 数量 是 (bytes 
requested)/sizeof(Base)。 第 二 ， 传 递 给 operator new[] 的 size_t 参数 可 能 比 充满 Objects 的 
内 存 还 要 大 一 些 ， 因 为 ， 就 像 ltem 16 讲 到 的 ，dynamically allocated arrays (动态 分 配 数 
组 ) 可 能 包括 额外 的 空间 用 于 存储 数组 元 素 的 数量 。 


编写 operator new 时 ， 你 需要 遵循 的 惯例 也 就 到 此 为 止 了 。 对 于 operator delete， 事 情 就 更 
简单 了 ， 你 需要 记 住 的 全 部 大 约 就 是 C++ 保证 删除 空 指针 总 是 安全 的 ， 所 以 你 需要 遵循 这 个 
保证 。 下 面 是 一 个 非 成 员 的 operator delete 的 伪 代 码 : 


void operator delete(void *rawMemory) throw() 


if (rawMemory == ©) return; // do nothing if the null 
// pointer is being deleted 


_deallocate the memory pointed to by rawMemory;_ 


} 


RADKA A hAth AA, RERU aR E RR k AAD. (Rik REY class- 
specific (类 专用 ) 的 operator new 将 “错误 "大 小 的 请 求 转发 给 operator new， 你 也 可 以 
将 "错误 大 小 "的 删除 请 求 转 发 给 ::operator delete : 

class Base { // same as before, but now 

public: // operator delete is declared 


static void * operator new(std::size_t size) throw(std::bad_alloc); 
**static void operator delete(void *rawMemory, std::size_t size) throw();** 


J; 
void Base::operator delete(void *rawMemory, std::size_t size) throw() 
if (rawMemory == 0) return; // check for null pointer 
**if (size != sizeof(Base)) {** // if size is "wrong," 
**::operator delete(rawMemory) ; ** // have standard operator 
**return; ** // delete handle the request 
Pe 
_deallocate the memory pointed to by rawMemory;_ 
return; 


有 趣 的 是 ， 如 果 被 删除 的 object 是 从 一 个 缺少 virtual destructor (虚拟 析 构 函数 ) 的 base 
class ( 基 类 ) 派生 出 来 的 ，C++ 传递 给 operator delete 的 size_t 值 也 许 是 不 正确 的 。 这 已 经 
足够 作为 “确保 你 的 base classes (22) 拥有 virtual destructors (虚拟 析 构 图 数 ) ”的 原因 
了 ， 除 此 之 外 ，ltem 7 描述 了 另 一 个 ， 论 证 得 更 好 的 原因 。 至 于 当前 ， 简 单 地 记 住 如 果 你 在 
base classes ( 基 类 ) 中 遗漏 了 virtual destructors (虚拟 析 构 范 数 ) , operator delete 
functions 可 能 无 法 正确 工作 。 


Things to Remember 


e operator new 应 该 包含 一 个 设法 分 配 内 存 的 无 限 循 环 ， 如 果 它 不 能 满足 一 个 内 存 请 求 ， 
应 该 调用 new-handler， 还 应 该 处 理 需 字 节 请 求 。class-specific 〈 类 专用 ) 版 本 应 该 处 理 
对 比 预 期 更 大 的 区 块 的 请 求 。 


e operator delete 如 果 收 到 一 个 空 指针 应 该 什么 都 不 做 。class-specific (类 专用 ) 版 本 应 
该 处 理 比 预期 更 大 的 区 块 。 


Item 52: 102245 T placement new， 就 要 编写 
placement delete 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


在 C++ MH, placement new 和 placement delete 并 不 是 最 常 遇 到 的 野兽 ， 所 以 如 果 你 
和 它们 不 熟 也 不 必 担 心 。 作 为 替代 ， 回 想 一 下 Items 16 和 17， 当 你 写 下 一 个 这 样 的 new R 


Widget *pw = new Widget; 


有 两 个 函数 会 被 调用 : 一 个 是 operator new 用 于 分 配 内 存 ， 第 二 个 是 Widget 的 default 
constructor (RB Mis WR) 。 


假设 第 一 个 调用 成 功 ， 而 第 二 个 调用 导致 抛 出 一 个 exception (#3) 。 这 种 情况 下 ， 第 1 步 
中 完成 的 内 存 分 配 必 须 被 撤销 。 否 则 就 是 一 个 内 存 泄漏 。 客 户 代码 不 可 能 回收 这 些 内 存 ， 
为 ， 如 果 Widget 的 constructor (A ERZ) 抛 出 一 个 exception (F) ，pw 根本 就 没有 
被 赋值 。 对 于 客户 来 说 无 法 得 到 指向 应 该 被 回收 的 内 存 的 指针 。 所 以 撤销 第 1 步 的 职责 必然 
落 在 了 C++ runtime system (C++ 运行 时 系统 ) 的 身上 。 


runtime system (运行 时 系统 ) 恰当 地 调用 与 它 在 第 1 步 中 调用 的 operator new 的 版 本 相对 
应 的 operator delete， 但 是 只 有 在 它 知道 哪 一 个 operator delete 可 能 有 许多 最 恰当 
的 时 候 它 才能 做 到 这 一 点 。 如 果 你 正在 摆弄 具有 常规 的 signatures (识别 特征 ) 的 new 和 
delete 版 本 ， 这 不 成 问题 ， 因 为 常规 的 operator new, 








void* operator new(std::size_t) throw(std::bad_alloc); 


对 应 常规 的 operator delete : 


void operator delete(void *rawMemory) throw(); // normal signature 
// at global scope 


void operator delete(void *rawMemory, // typical normal 
std::size_t size) throw(); // signature at class 
// scope 


当 你 只 使 用 new 和 delete 的 常规 形式 时 ，runtime system (运行 时 系统 ) 找 出 知道 如 何 撤销 
new 所 做 的 事情 的 delete 没什么 麻烦 。 然 而 ， 当 你 开始 声明 operator new 的 非常 规 形 式 一 一 
带 有 额外 参数 的 形式 的 时 候 ，which-delete-goes-with-this-new ( 哪 一 个 delete 和 这 个 new 配 


xt) 的 问题 就 出 现 了 。 


例如 ， 假 设 你 编写 了 一 个 class-specific (类 专用 ) 的 operator new， 它 需要 一 个 用 于 记录 分 
配 信息 的 ostream 的 规格 描述 ， 而 你 又 编写 了 一 个 常规 的 class-specific (类 专用 ) 的 
operator delete : 


class Widget { 


public: 
static void* operator new(std::size_t size, // non-normal 
std::ostream& logStream) // form of new 
throw(std::bad_alloc); 
static void operator delete(void *pMemory // normal class- 
std::size_t size) throw();  // specific form 


// of delete 


Ti 


这 个 设计 是 成 问题 的 ， 但 是 在 我 们 探究 为 什么 之 前 ， 我 们 需要 做 一 个 简要 的 术语 说 明 。 


当 一 个 operator new function 持 有 额外 的 参数 (除了 那个 必要 的 sizet 参数 ) ， 这 个 function 
就 被 称 为 new 的 _placement 版 本 。 前 面 那个 operator new 就 是 这 样 一 个 placement 版 本 。 

有 一 个 特别 有 用 的 placement new， 它 持 有 一 个 指针 ， 这 个 指针 指定 了 一 个 object 被 构造 的 

位 置 。 那 个 operator new 如 下 : 


void* operator new(std::size_t, **void *pMemory**) throw(); // “placement 
// new" 


new 的 这 个 版 本 是 C++ 标准 库 的 一 部 分 ， 只 要 #include <new> 你 就 可 以 访问 它 。 需 要 指 

出 ， 这 个 new 用 于 vector 内 部 ， 在 vector 的 尚未 使 用 的 空间 内 创建 objects。 它 也 是 最 初 的 
placement new. Kiel, AMER KARMA placement new 的 来 历 。 这 就 意味 着 术语 
"placement new" 被 赋予 了 更 多 的 含义 。 大 多 数 情况 下 ， 当 人 们 谈 到 placement new， 他 们 谈 
的 就 是 这 个 特定 的 函数 ， 持 有 一 个 void* 类 型 的 额外 参数 的 operator new。 较 少 情况 下 ， 他 们 
谈 的 是 持 有 人 额外 参数 的 operator new 的 任意 版 本 。 根 据 上 下 文通 常 可 以 搞 清楚 任何 暧昧 ， 重 
要 的 是 要 了 解 到 通用 术语 "placement new" 意味 着 持 有 额外 参数 的 new 的 任意 版 本 ， 因 为 短 
语 "placement delete" (过 一 会 儿 我 们 就 会 遇 到 它 ) 直接 起 源 于 它 。 


我 们 让 我 们 先 返回 到 Widget class 的 declaration (AA) ， 就 是 我 说 设计 成 问题 的 那个 。 麻 
烦 就 在 于 这 个 class 会 引发 微妙 的 memory leaks (内 存 泄漏 ) 。 考 虑 如 下 客户 代码 ， 在 动态 
创建 一 个 Widget 时 ， 它 将 在 cerr 记录 分 配 信息 : 

Widget *pw = new (std::cerr) Widget; // call operator new, passing cerr as 


// the ostream; _this leaks memory_ 
// _if the Widget constructor throws_ 


重申 一 次 ， 如 果 内 存 分 配 成 功 而 Widget constructor GERA 抛 出 一 个 exception (= 
常 ) ，runtime system (运行 时 系统 ) 有 责任 撤销 operator new 所 执行 的 分 配 。 然 而 ， 
runtime system (运行 时 系统 ) 不 能 真正 了 解 被 调用 的 operator new 版 本 是 如 何 工作 的 ， 所 
以 它 自己 无 法 撤销 那个 分 配 。runtime system (运行 时 系统 ) 转 而 寻找 一 个 和 operator new 
持 有 相同 数量 和 类 型 额外 参数 的 operator delete 版 本 ， 而 且 ， 如 果 它 找到 了 ， 它 将 调用 它 。 
在 当前 情况 下 ，operator new 持 有 一 个 ostream& 类 型 的 额外 参数 ， 所 以 相应 的 operator 
delete 应 该 具有 这 样 的 signature (识别 特征 ) 


void operator delete(void *, **std::ostream&**) throw(); 


& new 的 placement 版 本 类 似 ， 持 有 人 额外 参数 的 operator delete 版 本 被 称 为 placement 
deletes。 当 前 情况 下 ，Widget 没有 声明 operator delete 的 placement 版 本 ， 所 以 runtime 
system (运行 时 系统 ) 不 知道 如 何 撤 销 所 调用 的 placement new 所 做 的 事情 。 结 果 ， 它 什么 
都 不 做 。 在 本 例 中 ， 如 果 Widget constructor (44352920) 抛 出 一 个 exception (异常 ) ， 没 
有 operator delete 可 以 被 调用 ! 


规则 很 简单 : 如 果 一 个 带 有 额外 参数 的 operator new 没有 带 有 同样 额外 参数 的 operator 
delete 相 匹 配 ， 当 一 个 由 new 生成 的 内 存 分 配 需要 撤销 的 时 候 没有 operator delete 可 以 被 调 
用 。 为 了 消除 前 面 的 代码 中 的 memory leak (内 存 泄漏 ) ，Widget 需要 声明 一 个 与 logging 
placement new 相对 应 的 placement delete : 

class Widget { 

public: 

static void* operator new(std::size_t size, std::ostream& logStream) 
throw(std::bad_alloc); 


static void operator delete(void *pMemory) throw(); 


**static void operator delete(void *pMemory, std::ostream& logStream) ** 
**throw();** 


ee 


这 样 改变 之 后 ， 如 果 从 下 面 这 个 语句 的 Widget constructor (ERAO 中 抛 出 一 个 
exception (异常 ) , 


Widget *pw = new (std::cerr) Widget; // as before, but no leak this time 


相应 的 placement delete 自动 被 调用 ， 而 这 就 让 Widget 确保 没有 内 存 被 泄漏 。 


然而 ， 考 虑 以 下 情况 会 发 生 什 么 ， 如 果 没 有 抛 出 exception (异常 ) (这 是 通常 的 情况 ) 而 我 
们 的 客户 代码 中 又 有 一 个 delete : 


delete pw; // invokes the normal 
// operator delete 


就 像 注 释 中 所 说 的 ， 这 样 业 调用 常规 operator delete, M7 placement 版 本 。 只 有 在 调用 
一 个 与 placement new 相关 联 的 constructor (ERA) 时 发 生 一 个 exception (FH) , 
placement delete 才 会 被 调用 。 将 delete 施加 于 一 个 指针 (诸如 上 面 的 pw) 绝对 不 会 引起 一 
个 delete 的 placement 版 本 的 调用 。 绝 对 不 会 。 


这 就 意味 着 为 了 预防 所 有 与 new 的 placement 版 本 相关 的 memory leaks (AFR) ， 你 
必须 既 提 供 常 规 operator delete 〈 用 于 构造 过 程 中 没有 抛 出 exception (异常 ) 时 ) ， 又 要 提 
供 一 个 持 有 与 operator new 相同 的 extra arguments (额外 参数 ) 的 placement 版 本 (用 于 
相反 情况 ) 。 这 样 ， 你 就 再 也 不 会 因为 微妙 的 memory leaks (AFR) MEARS RT. E 
吧 ， 至 少 是 不 会 因为 这 里 这 些微 妙 的 memory leaks (AFH) 。 


顺便 说 一 下 ， 因 为 member function (X AWM) 的 名 字 会 覆盖 外 围 的 具有 相同 名 字 的 函数 
(参见 Item 33) ， 你 需要 小 心 避免 用 class-specific (类 专用 ) 的 news 覆盖 你 的 客户 所 希望 

看 到 的 其 它 news (包括 其 常规 版 本 ) 。 例 如 ， 如 果 你 有 一 个 只 声明 了 一 个 operator new 的 

placement 版 本 的 base class ( 基 类 ) , BPR new 的 常规 形式 对 他 们 来 说 无 法 使 用 : 


class Base { 


public: 
static void* operator new(std::size_t size, // this new hides 
std::ostream& logStream) // the normal 
throw(std::bad_alloc); // global forms 
J; 
Base *pb = new Base; // error! the normal form of 
// operator new is hidden 
Base *pb = new (std::cerr) Base; // fine, calls Base's 


// placement new 


同样 ，derived classes (派生 类 ) 中 的 operator news Æ% operator news 的 全 局 和 继承 来 的 
版 本 的 operator new : 

class Derived: public Base { // inherits from Base above 

public: 


static void* operator new(std::size_t size) // redeclares the normal 


throw(std::bad_alloc); // form of new 
J; 
Derived *pd = new (std::clog) Derived; // error! Base's placement 
// new is hidden 
Derived *pd = new Derived; // fine, calls Derived's 


// operator new 


ltem 33 讨论 了 这 种 名 字 履 盖 的 需要 考虑 的 细节 ， 如 果 打 算 编 写 内 存 分 配 函 数 ， 你 要 记 住 ， 在 
缺 省 情况 下 ，C++ 在 全 局 范围 提供 如 下 形式 的 operator new : 


void* operator new(std::size_t) throw(std::bad_alloc); // normal new 


void* operator new(std::size_t, void*) throw(); // placement new 
void* operator new(std::size t, // nothrow new 一 
const std::nothrow_t&) throw(); // see [Item 49](http://blog. 
1 = 








如 果 你 在 一 个 class 中 声明 了 任何 operator news， 都 将 覆盖 所 有 这 些 标准 形式 。 除 非 你 有 意 
防止 class 的 客户 使 用 这 些 形 式 ， 否 则 ， 除 了 你 创建 的 任何 自 定义 new 形式 以 外 ， 还 要 确保 
它们 都 可 以 使 用 。 当 然 ， 还 要 确保 为 每 一 个 你 使 其 可 用 的 operator new 提供 相应 的 operator 
delete。 如果 你 要 这 些 函 数 具 有 通常 的 行为 ， 只 需要 让 你 的 class-specific (类 专用 ) 版 本 去 

调用 global (全 局 ) 版 本 即 可 。 


达到 这 种 效果 的 一 个 简单 方法 是 创建 一 个 包含 new 和 delete 的 全 部 常规 形式 的 base 
class ( 基 类 ) 


class StandardNewDeleteForms { 
public: 
**// normal new/delete** 
static void* operator new(std::size_t size) throw(std::bad alloc) 
{ return ::operator new(size); } 
static void operator delete(void *pMemory) throw() 
{ ::operator delete(pMemory); } 


**// placement new/delete** 

static void* operator new(std::size_t size, void *ptr) throw() 
{ return ::operator new(size, ptr); } 

static void operator delete(void *pMemory, void *ptr) throw() 
{ return ::operator delete(pMemory, ptr); } 


**// nothrow new/delete** 

static void* operator new(std::size_t size, const std::nothrow_t& nt) throw() 
{ return ::operator new(size, nt); } 

static void operator delete(void *pMemory, const std::nothrow_t&) throw() 

{ ::operator delete(pMemory); } 


}; 


想 要 在 标准 形式 之 外 增加 自 定义 形式 的 客户 就 能 够 使 用 inheritance (继承 ) 和 using 
declarations (使 用 声明 ) (参见 Item 33) 来 得 到 标准 形式 : 


class Widget: public StandardNewDeleteForms { // inherit std forms 
public: 
using StandardNewDeleteForms: :operator new; // make those 
using StandardNewDeleteForms::operator delete; // forms visible 
static void* operator new(std::size_t size, // add a custom 


std::ostream& logStream) // placement new 
throw(std::bad_alloc); 


static void operator delete(void *pMemory, // add the corres- 
std::ostream& logStream) // ponding place- 
throw(); // ment delete 


val 


Things to Remember 


。 在 编写 一 个 operator new 的 placement 版 本 时 ， 确 保 同时 编写 operator delete 的 相应 的 
placement 版 本 。 否 则 ， 你 的 程序 可 能 会 发 生 微妙 的 ， 断 续 的 memory leaks (内 存 泄 
漏 ) 。 


e 当 你 声明 new 和 delete 的 placement 版 本 时 ， 确 保 不 会 无 意 中 履 盖 这 些 函 数 的 常规 版 
本 。 


附录 A. 超越 Effective C++ 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


Effective C++ 覆盖 了 我 认为 对 当前 的 C++ 程序 员 最 重要 的 通用 指导 方针 ， 但 是 如 果 你 有 兴趣 
在 更 多 的 方面 提升 你 的 效力 ， 我 推荐 你 去 研读 我 的 其 他 C++ 书籍 ，More Effective C++ 和 
Effective STL. 


More Effective C++ 覆盖 其 它 的 编程 指导 方针 ， 并 包括 像 效 率 和 带 有 异常 编程 这 样 的 话题 的 广 
泛 讨 论 。 它 也 记述 了 像 smart pointers (智能 指针 ) ，reference counting (引用 计数 ) 和 
proxy objects (RIER) 这 样 的 重要 的 C++ 编程 技术 。 


Effective STL 像 Effective C++ 一 样 是 一 本 面向 指导 方针 的 书 ， 但 是 它 专 注 于 标准 模板 库 的 有 
效 使 用 。 


下 面 是 这 两 本 书 的 目录 摘要 。 

Contents of More Effective C++ 

Basics 

Item 1: Distinguish between pointers and references 

Item 2: Prefer C++-style casts 

Item 3: Never treat arrays polymorphically 

Item 4: Avoid gratuitous default constructors 

Operators 

Item 5: Be wary of user-defined conversion functions 

Item 6: Distinguish between prefix and postfix forms of increment and decrement operators 
Item 7: Never overload &&, ||, or, 

Item 8: Understand the different meanings of new and delete 
Exceptions 

Item 9: Use destructors to prevent resource leaks 


Item 10: Prevent resource leaks in constructors 


Item 11: Prevent exceptions from leaving destructors 


Item 12: Understand how throwing an exception differs from passing a parameter or calling a 
virtual function 


Item 13: Catch exceptions by reference 

Item 14: Use exception specifications judiciously 
Item 15: Understand the costs of exception handling 
Efficiency 

Item 16: Remember the 80-20 rule 

Item 17: Consider using lazy evaluation 

Item 18: Amortize the cost of expected computations 
Item 19: Understand the origin of temporary objects 
Item 20: Facilitate the return value optimization 

Item 21: Overload to avoid implicit type conversions 
Item 22: Consider using op= instead of stand-alone op 
Item 23: Consider alternative libraries 


Item 24: Understand the costs of virtual functions, multiple inheritance, virtual base classes, 
and RTTI 


Techniques 

Item 25: Virtualizing constructors and non-member functions 

Item 26: Limiting the number of objects of a class 

Item 27: Requiring or prohibiting heap-based objects 

Item 28: Smart pointers 

Item 29: Reference counting 

Item 30: Proxy classes 

Item 31: Making functions virtual with respect to more than one object 
Miscellany 


Item 32: Program in the future tense 


Item 33: Make non-leaf classes abstract 

Item 34: Understand how to combine C++ and C in the same program 
Item 35: Familiarize yourself with the language standard 

Contents of Effective STL 

Chapter 1: Containers 

Item 1: Choose your containers with care. 

Item 2: Beware the illusion of container-independent code. 

Item 3: Make copying cheap and correct for objects in containers. 
Item 4: Call empty instead of checking size() against zero. 

Item 5: Prefer range member functions to their single-element counterparts. 
Item 6: Be alert for C++'s most vexing parse. 


Item 7: When using containers of newed pointers, remember to delete the pointers before 
the container is destroyed. 


Item 8: Never create containers of auto_ptrs. 

Item 9: Choose carefully among erasing options. 

Item 10: Be aware of allocator conventions and restrictions. 

Item 11: Understand the legitimate uses of custom allocators. 
Item 12: Have realistic expectations about the thread safety of STL containers. 
Chapter 2: vector and string 

Item 13: Prefer vector and string to dynamically allocated arrays. 
Item 14: Use reserve to avoid unnecessary reallocations. 

Item 15: Be aware of variations in string implementations. 

Item 16: Know how to pass vector and string data to legacy APIs. 
Item 17: Use "the swap TRick" to trim excess capacity. 

Item 18: Avoid using vector<bool>. 

Chapter 3: Associative Containers 


Item 19: Understand the difference between equality and equivalence. 


Item 20: Specify comparison types for associative containers of pointers. 
Item 21: Always have comparison functions return false for equal values. 
Item 22: Avoid in-place key modification in set and multiset. 

Item 23: Consider replacing associative containers with sorted vectors. 


Item 24: Choose carefully between map::operator[] and map::insert when efficiency is 
important. 


Item 25: Familiarize yourself with the nonstandard hashed containers. 

Chapter 4: Iterators 

Item 26: Prefer iterator to const_iterator, reverse_iterator, and const_reverse_iterator. 
Item 27: Use distance and advance to convert a container's const_iterators to iterators. 
Item 28: Understand how to use a reverse_iterator's base iterator. 

Item 29: Consider istreambuf_iterators for character-by-character input. 

Chapter 5: Algorithms 

Item 30: Make sure destination ranges are big enough. 

Item 31: Know your sorting options. 

Item 32: Follow remove-like algorithms by erase if you really want to remove something. 
Item 33: Be wary of remove-like algorithms on containers of pointers. 

Item 34: Note which algorithms expect sorted ranges. 


Item 35: Implement simple case-insensitive string comparisons via mismatch or 
lexicographical_ compare. 


Item 36: Understand the proper implementation of copy_if. 
Item 37: Use accumulate or for_each to summarize ranges. 
Chapter 6: Functors, Functor Classes, Functions, etc. 

Item 38: Design functor classes for pass-by-value. 

Item 39: Make predicates pure functions. 

Item 40: Make functor classes adaptable. 


Item 41: Understand the reasons for ptr_fun, mem_fun, and mem_fun_ref. 


Item 42: Make sure less<T> means operator<. 

Chapter 7: Programming with the STL 

Item 43: Prefer algorithm calls to hand-written loops. 

Item 44: Prefer member functions to algorithms with the same names. 


Item 45: Distinguish among count, find, binary_search, lower_bound, upper_bound, and 
equal_range. 


Item 46: Consider function objects instead of functions as algorithm parameters. 
Item 47: Avoid producing write-only code. 

Item 48: Always #include the proper headers. 

Item 49: Learn to decipher STL-related compiler diagnostics. 


Item 50: Familiarize yourself with STL-related web sites. 


附录 B. 第 二 和 第 三 版 之 间 的 Item BRET 


作者 : Scott Meyers 
译 者 : fatalerror99 (iTePub's Nirvana) 
发 布 : http://blog.csdn.net/fatalerror99/ 


Effective C++ 的 第 三 版 在 很 多 方面 与 第 二 版 不 同 ， 其 中 最 引 人 注 目的 是 它 包 含 很 多 新 的 信 
息 。 然 而 ， 第 二 版 的 大 部 分 内 容 依然 保留 在 第 三 版 中 ， 虽 然 经 常会 改变 形式 和 位 置 。 在 后 面 
几 页 的 表格 中 ， 我 展示 了 第 二 版 Items 中 的 信息 在 第 三 版 的 哪里 可 以 找到 ， 反 之 亦 然 。 


这 个 表 展 示 了 一 个 信息 的 上 映射， 而 不 是 文本 的 。 例 如 ， 第 二 版 的 Item 39 中 的 思想 (“避免 在 
继承 体系 中 做 向 下 转型 (cast down) 动作 ”) (此 标题 借用 侯 捷 先生 的 第 二 版 译文 一 一 译 者 
注 ) 现在 可 以 在 当前 版 本 的 Item 27 (“最 少 化 casting (强制 转型 ) ”) 中 找到 ， 即 使 第 三 版 这 
个 Item 的 文本 和 例子 完全 是 新 的 。 一 个 更 极端 的 例子 在 于 第 二 版 的 Item 18 (“努力 让 接口 完 
满 (complete) 且 最 小 化 ”) (此 标题 借用 修 捷 先生 的 第 二 版 译文 一 译 者 注 ) 。 那 个 ltem 的 
主要 结论 之 一 是 : 不 需要 对 non-public (〈 非 公有 ) 构件 进行 特殊 访问 的 prospective member 
functions (候选 成 员 画 数 ) 一 般 应 该 成 为 non-members ( 非 成 员 ) 。 在 第 三 版 中 ， 通 过 不 同 
的 (更 强 的 ) 论证 达到 相同 的 结果 ， 所 以 第 二 版 中 的 Item 18 映射 到 第 三 版 中 的 Item 23 (“用 
non-member non-friend functions ( 非 成 员 非 友 元 函数 ) 取代 member functions (Ak A E 

数 ) ”) ， 即 使 这 两 个 Item 之 间 仅 有 的 共同 之 处 是 它们 的 结论 。 


Second Edition to Third Edition 


2nd Ed. 3rd Ed. 2nd Ed. 3rd Ed. 2nd Ed. 3rd Ed. 


1 2 18 23 35 32 
2 - 19 24 36 34 
3 - 20 22 37 36 
4 - 21 3 38 37 
5 16 22 20 39 27 
6 13 23 21 40 38 
7 49 24 - 41 41 
8 51 25 - 42 39 
9 52 26 - 43 44, 40 
10 50 27 6 44 - 
11 14 28 - 45 5 
12 4 29 28 46 18 
13 4 30 28 47 4 
14 K 31 21 48 59 
15 10 32 26 49 54 
16 12 33 30 50 > 
17 11 34 31 


Third Edition to Second Edition 


3rd Ed. 


— 


o oo Nn Oo a A W ND 


10 


2nd Ed. 


1 
21 
12, 13, 47 
45 
27 
14 


pp. 77-79 


3rd Ed. 
20 
2a 
22 
23 
24 
29 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 


2nd Ed. 
22 
23,31 
20 
18 


3rd Ed. 


2nd Ed. 
42 
43 
41 


42 


